Dead Green Servers

In a recent post, I relayed the information that the GE migration to the Linux server had to take place because the Sun Solaris servers upon which Centricity had been based were now at end-of-life status. In particular, the most recent version used for Centricity, the SunFire V480, is "retired and no longer orderable" according to Sun's website.

But wait, all is not lost! It seems that the SunFire V490 is now available to meet all your Solaris needs, and you can get it from $30,995.00 (US). Could it have done the job for Centricity? More than likely:

Pack your racks with UltraSPARC IV+ processors driving this 5 RU server and get over 5x faster performance compared to UltraSPARC III based Sun Fire V480 servers. Up to four processors per box with eight threads and 64GB of memory make it ideal for securing and delivering multiple applications and business processes or distributed databases.

Yeah, I think the V490 is probably beyond the V480's capabilities:

The Sun Fire™ V480 server is designed to deliver compute density and enterpriseclass RAS features at an affordable price. Its space-efficient, rack-optimized 5RU, 24-inch-depth enclosure provides excellent value per rack unit and contains up to four 1.05/1.2-GHz UltraSPARC® III Cu processors, each with 8 MB cache(L2), up to 32 GB of memory, integrated dual 10/100/1000-Mb/sec. Ethernet, and the Sun Fireplane Interconnect operating at 9.6 GB/sec.

OK, so what's the real reason behind the upgrade? Well, I dunno. To be fair, GE has been selling the Linux servers for several years, well before the Dynamic Imaging acquisition. And far be it from me to criticize them for being willing to change some software that I was not terribly pleased with in the first place. But was it the server reaching end-of-life that forced the issue? Or the software?

Dalai Does Dallas

I had a rather quick turn-around last week. I arrived back home from New Orleans at 5 P.M., and had to fly out to the West the next morning. We were booked on American Airlines, and we knew this was going to be problematic when the ticket agent predicted American's bankruptcy within the next 6 months. Always reassuring before a flight. To make matters worse, I used my smartphone to check for the connecting gate in Dallas, and lo and behold, it had been cancelled. Fortunately, we were able to rebook on US Air to our destination, and all was well.

American blamed the cancellation on weather in Dallas, and truly there was a big storm there that day. However, the storm lasted less than an hour, and I personally think American was looking for excuses to suspend flights and save fuel. Maybe that's why they tell some of their gate agents to be nasty to the flying public; one less customer, one less gallon. However, given their rather unfortunate habit of letting their planes sit idling with the engines running while waiting for their gates to clear probably eats more fuel than they save with cancelled flights and lost customers. Scratch one more airline.

I actually wasn't planning to travel again quite so soon, but I received a call from Amicas asking me to fly out West to speak with some potential customers. They thought the doctor-to-doctor thing might be helpful, since the group was somewhat similar to mine, and what they wanted to do with the product was rather close to the way we use it. So, off I went. Lest anyone dare call this a junkett, I'll reiterate that I really didn't want to go anywhere at that time, and I certainly wasn't interested going West where the temperatures were well above 100 degrees. But faith in the product, and maybe a little vanity, made me decide to do it anyway.

The radiology group in question is sort of like mine, about the same size, with a few guys older than I am, and more that are younger. They are rather spread out, covering several towns rather far from their base, as do we.

Now, I won't reveal the particulars this group sought, but portability was a critical factor. They had narrowed their choices down to Amicas and another company, and they were having some trouble deciding beyond that. On the advice of my very wise, and occasionally politically-correct friend, Mike Cannavo, the One and Only PACSMan, I won't name the other company, but suffice it to say they are definitely one of the BIGGER players.

I had the chance to speak briefly with some of my counterparts in this Western group, as well as their IT guru. It became clear that they saw the viewers of both PACS as equal. They made the assumption that both could serve their needs, but they still had some hesitation about Amicas as a smaller company vs. the "security" of the BIGGER company. I'm not sure I got all of my points across in person, but I'm told that many of them read this blog, so here is everything I should have said, just in case I didn't.

First and foremost, Amicas is a scrappy little company that isn't going anywhere. I'm always seeing something on AuntMinnie.com about how little PACS companies are going to either die or be taken over. That's true for some, but I don't include Amicas in that pile. They have a great deal of money in the bank, the company is buying back its stock, and 20% of revenue goes into R&D. It is acquiring new technology such as RadStream (the acute-event reporting software from Cincinnati Children's that I have discussed elsewhere.) Sure, if some company like Siemens offered them double what they are now worth, I'm sure they would sell out (I would), but I don't see that happening any time soon. Let's put this takeover idea to bed for today, shall we?

Somehow, there has emerged the illusion that there is safety with purchasing from the BIGGER company. Hmmmmmm... Just ask anyone who bought Centricity in the last few years how safe that is. Or the old Philips PACS made by Sectra. Sadly, the BIGGER folks have an easier time of buying some new technology and requiring a forklift upgrade (usually hardware needs replacing as well as software in these circumstances) for you and me to get it. And, they are not worried (at least not as much as they should be) about whether or not you and I will pony up the charge for the next latest and greatest. After all, the BIGGER company was the safe bet, wasn't it? I can't see that we are particularly worse off dealing with a smaller company that isn't looking to swap out its product for something new, rather than improve and grow what it has. There are those who still believe the old "no one gets fired for choosing BIGGER" philosophy, but I guess I'm not in charge of their particular operation.

Only a few of the BIGGER folks have totally web-based technology, but most don't, and that is the case with the BIGGER company in question here. Is that a problem? Well, it depends upon how many software clients you wish to play with. Amicas has just one GUI, called LightBeam, which is deployed over the web to anywhere you happen to have a computer and broadband. To be totally accurate, there is a second client called LightView, that is simply LightBeam without a couple of features such as spine labelling. Which client and features are activated depends upon your status as a radiologist, clinician, tech, etc. Our friends at the BIGGER company seem to use several clients, some thin, some thick, and as I understand it, I could not put the thick client on my computer myself without help (authorization, I guess) from IT or the PACS team. Hmmmm.

How does the system distribute images? Most everyone is now going to a central repository. Amicas basically ties a web-server to a SQL database. (Note: Amicas now uses the IBM DB2 database which in turn runs SQL.) Why reinvent the wheel? This architecture works pretty well for other web applications, so why not use it? Is this what the BIGGER company does? Well, to some extent, but there seems to be a lot more complexity added, without necessarily getting a lot of additional advantage. This could be quite critical to my new friends out West, as their enterprise spreads far and wide, and the way the system deals with connectivity (or the lack thereof) could make or break the system. Amicas will allow a modality to automatically resume sending once a broken communication line is repaired. It seems that the BIGGER company requires a manual resend in this situation. Could be a problem.

Service should be a given. I've had a few glitches with Amicas service, but our downtime on our group's system has totaled only an hour or two in two years, and most things get caught before they cause chaos. I sure can't say that about some of the BIGGER companies I deal with daily. As for the BIGGER company I'm referring to here....well, I'll let someone else answer for them.

To me, the background operations don't matter as much as the actual interface, the client, the GUI. I like the way Amicas works. It doesn't get in my way, and it lets me bang through studies as fast as I feel comfortable doing so. Can we say this about the BIGGER GUI? I guess it depends upon which one of the options you actually use in practice.

Bottom line here is that BIGGER is not necessarily better. Look honestly at the products themselves, with no preconceived notions about BIGGER companies being safer than smaller companies, and the like. See what works for you and your group, and be sure they all get time on the GUI before you sign on the line. You might find that smaller works for you. I have lived through situations where the purchase was directed to the BIGGER, "safer" choice, and for three times the expenditure, we got half the product.

And no, I don't get a commission, so I have no vested interest in which way my friends out West decide to go. But I'm sure they will make an informed choice. They DO read my blog, after all!

P.S. No, the BIGGER company in question is not the one you think it is. I would have said bigGEr were that the case.

NO RIP for eRAD

According to a very reliable source, eRAD had given up the corporate ghost. HOWEVER, I just heard from a friend at eRAD that they are alive and kicking, so word of their demise is premature. Glad to hear it! My sincerest apologies to eRAD and my friends there, but I promise my source was trustworthy in the extreme! Perhaps his/her unimpeachable source needs to be impeached.

It seems that I have more readers than I ever will admit to myself, and it seems that a bunch of them were burning up the lines to eRAD. I've learned my lesson, I think, about posting unsubstantiated rumours.

To further my mea culpa, I will reproduce an e-mail from Seth Koeppel, eRAD's Senior VP of Sales:

All is well at eRAD, no danger of going out of business. With roughly 220 customers (300+ sites) of various shapes and sizes we're fortunate to be able to sustain ourselves (at a pretty full staff I might add) on residual support contracts, upgrades, expansions and add on sales from existing customers.

With this said I will tell you it's a tough market. Lots of opportunity but not a lot of checks being written right now. So we took the painful step a few weeks ago of reducing staff by a whopping 4 heads (2 direct sales, 1 apps and 1 field support) to ensure we can run at a 'zero footprint' or break even. One of the sales guys went back to work for our best reseller where we originally hired him so no real loss there and a better fit for him. If sales pick back up we'll add the heads back.

We continue to see steady activity from our network of resellers which has been erad's primary sales vehicle. While distributing through resellers can be a challenge it does have some advantages in a down market. If you stop and consider where much of the spend is in pacs right now its the small community hospitals and non-critical care access providers that haven't yet gone digital. There are literally thousands of ortho, multi-specialty, urgent care, etc. Clinics and small imaging centers that have yet to go digital and these are best served by the resellers who've been supplying film, chemistry and service to them for years. I just don't see how a company can afford a direct sales force to reach this market? Particularly with the cost of fuel/travel being what it is I think the regional guys have a huge advantage from a 'cost of sales' perspective and the margin on the low end systems aren't all that appealing for the big guys.

Then there's the replacement market. Talking to Ben Brown from KLAS at SIIM (you were missed by the way) he shared an interesting bit of info with me. He indicated they surveyed both the vendors and the hospitals on what they felt the replacement market is. The vendors weighed in at 40%+ and the hospitals 10%. I think there is some merit to this disconnect. The pacs the hospitals paid big bucks for just a few years ago does what they need it to do. Its the rads and the referrings who are beating the drum for web-based and remote reading to become more efficient and frankly I don't see the hospitals giving a hoot. Certainly not enough to spend the big dollars to make the rads more efficient so they can make more money.

This brings me back to my hot button of 'enterprise reading' or 'worklist consolidation'. I think the market is going to realize that A) hospitals aren't going to rush to upgrade and B) if they do the rads are still left reading from multiple disparate systems which doesn't allow for maximum efficiency of the most expensive resource in the production line. I've seen enough large groups pursuing purchasing their own system and requiring images be sent to it to know this is not just a passing fad but a reality of how groups will need to work in order to grow their reading base and improve efficiency.

This is where our direct sales efforts come in to play as the HL7 interfacing and complex workflow require a certain acumen and experience.

ERAD's technology is very progressive and very configurable so we have a big advantage in this space with some experience vis-a-vi our telerad providers and others whom have endeavored.

Then there are still some of the big guys who need a web based system (Cerner, McKesson, Siemens) to name a few not to mention companies like Sage/Medical Manager who still sell DI integrated to their RIS which is now owned by GE.....a direct competitor. Than there is the whole world of EMR companies who will no doubt want a web based image management component for their customers who do in office imaging and want to access images directly from the EMR in the context of the patient record and not have to go search a pacs worklist. Our API web interface allows this and we're seeing growing interest.

So I see lots of opportunity for a company with a solid platform, good developers, support infrastructure and 9 years of operating history.Everyone is feeling the pain with GE announcing a reduction of 400 heads in their imaging division today and Emageon's management losing its proxy fight with its investors which will no doubt result in a sale to the highest or for that matter any bidder.

So we're still here and will be for the foreseeable future. Hard to convince the world a small little company in Greenville SC can challenge the big guys and win but if anyone stops long enough to dig into the details they too will learn what several others have.

Hope to see you soon!

Seth

And that's all I have to say about that.

A Nuclear Oasis

I told a minor mistruth in the last post. It seems that a company called Segami has a product called Oasis that does much of what MIMVista's fusion product offers. I'll let you peruse their literature via this link.

Seeing it in action is impressive, but somewhat less so than the MIMVista product. Yes, it would link two studies, but some of the landmarks did not quite match as well as those on the MIMVista demo product. Could MIM have used better scan data? Maybe. Some of the tools on Oasis were a bit less intuitive at first blush, especially those that are used to alter the registration that I would have hoped to have been perfect when performed automatically. It did propogate ROI's from the old study to the new, as does MIM's, but not quite as well. There seems to be no deforming option, nor is there use of gradient-based edge detection.

I was told the system was web-based, and if you have more than one user, it is sold as a client-server operation. I didn't get a price on the PET module itself.

However, as it turns out, Segami writes the software for the Philips JETStream computer, which replaced the venerable ADAC Pegasys machines. We need a bunch of them, as our Pegasyses (Pegasi?) are rather old and decrepit at the moment, and Sun Workstations are just so 1990's. I was quoted a price for the client-server software, an adequate number of licenses, and the PET/CT product thrown in which was less than the price of one and one-half JETStream workstations from Philips. Now, whether the Segami product can do some of the special things offered by Philips, such as the rapid-acquisiton ASTONISH protocol, is yet to be determined.

As for PET/CT, I'll give MIMVista a 9.5, and I'll give Oasis an 8.5, based on limited exposure. You can rest assured, there will be more to come on this topic.

(MIM)Vistas of New Orleans

The annual meeting of the Society of Nuclear Medicine is held in various cities, including New Orleans, San Antonio, Philadelphia, Orlando, and Toronto. This year's meeting is rather poignant, as this is the first time the SNM has returned to New Orleans since Hurricane Katrina. The Morial Convention Center is in great shape; you would never know of the tragedies that occured within its walls and nearby. However, within a few miles of the convention center, and only a mile or so from the French Quarter, lies the Ninth Ward, and there we found that all is not well with New Orleans. Much destruction remains, and rebuilding is slow and patchy. Further north, near Lake Ponchatrain, there is even more devastation, and three years after Katrina, little has been fixed. Locals tell us that over 60,000 people left New Orleans, never to return, and their homes will sit barren for the foreseeable future, testaments to a complete failure of government at all levels, especially local.

Bourbon Street is as lively as ever, perhaps slightly cleaner than it was on my last visit several years ago. Alcohol flows freely, and the strip clubs dominate the landscape. My fourteen-year-old son (who looks fourteen) was offered Jello-shots, among other things, which he wisely declined, as Mrs. Dalai and I were looking on. One of the street hawkers asked me if I wanted to buy my son his first lap-dance. I smiled and didn't respond, but I reviewed the possible answers: "No, he's only fourteen." Or, "No, but when do I get my first lap-dance?" Or, "Let him buy his own!" Mrs. Dalai was not amused. She was even less amused when a stripper outside a club called to her, "Hey, I'll play with you too, baby-doll!" There is no place like Bourbon Street. I like to come here every five to ten years just to remind myself why I don't want to come here any more often than that.

I'm somewhat surprised that this city exists at all, let alone the fact that it survived the one-two punch from Katrina and Rita. There's a joke around these parts: "Look up. What do you see? Sea level." Yes, New Orleans sits anywhere from 1 to 15 feet below sea-level. Minor problem, eh? But, the spirit here is strong, the levees and pumps have been repaired, and the rebuilding goes on. Eventually, I predict New Orleans will return to its former grandeur.

But now, back to things medical.

I had the chance to speak with several folks from MIMVista, including the fellow that wrote the software for the iPhone 3G application. The company was kind enough to give me the link to the presentation at WWDC08 in San Fransisco:

As it turns out, the iPhone app cannot be demo'ed at this point due to some pesky NDA's MIMVista signed with Apple. But as per the last post, the software should launch with the iPhone 3G itself.

The real news here is the core MIMVista software itself. For us PET/CT readers, what they offer is nothing short of revolutionary. To understand this, you have to realize what it is I do when I read PET's. If I'm looking at a new study, I try to find the "hot spots," and determine if they are physiological or pathological. If the latter, I need to determine how hot they are, a measurement called SUV, or Standard Uptake Value, which is a ratio that tells us how hot the lesion is relative to the total distributed dose. A somewhat arbitrary value of 2.5 has been assigned to badness; in other words, if a lesion is 2.5 or more times hotter than the "average" activity in the body, we should worry that it is malignant, or at least infectious or inflammatory.

MIMVista's software won't actually find the hot spots for you (no doubt they are working on that) but once you locate them, MIM does the rest. Simply focus in on the lesion, and let the PET edge tool take over. It will find the contour of the lesion in three dimensions, and report back all the needed statistics such as minimum and maximum SUV, HU's (density from the CT component), and the volume of the lesion. MIMVista uses a unique, proprietary edge detection system that uses a gradient-based algorithm as opposed to the constant threshold algorithm used by everyone else in the business. See this paper if you want the details.

This would be adequate in and of itself. But as Apple's Steve Jobs himself says, "Oh, and one more thing...." The bane of my existence as a PET/CT reader is the comparison of the current study to one or more priors. MIMVista has attacked this problem, and has the only real solution I have encountered. This is multi-faceted, and very, very well thought-out. The system will automatically match the old study to the new. Voxar told me years ago that they were working on this, but they have yet to deliver it. In addition, the system will propagate the contours around the lesions from the prior study to the lesions on the current study. That may not sound like much, but trust me, this could be an absolute miracle for us readers. The lesion contours can be transferred rigidly, or can be deformed, and will automatically adjust to the new pattern of the finding. This is what the clinicians (and sometimes the patients themselves) want to see. Tell me the progression of the SUV and the size of the lesion. Measuring all of this manually for every lesion for every study is incredibly tedious and prone to error. I'll take every bit of help I can get, and MIM is offering me a heck of a lot of assistance.

MIMVista's system is made up of modules,

which as I understand it can be used separately, or together, with or without the "PACS" storage server. The "viewer" is a thin client, but supposedly not for diagnosis. However, the "thick" fusion module should work on all workstations with a fairly open license agreement. As of now, there is no integration to Agfa, which I would need for reading PETs done at my Agfa. Let's get to work on this, Agfa and MIM. Quickly. I really, really want to get my hands on this software.

I looked briefly at the Cardiac package, which would be great for those doing multimodality PET perfusion/CCTA scans. At the moment, it doesn't have the high-level CCTA angiographic controls and so forth that we need for readout of CCTA alone.

I didn't demo the Neuro package, but I have been told by other docs that it is quite advanced.

I was asked not to mention numbers, but I can say that the value for the price is absolutely phenomenal. This is a bargain folks, and I don't say that often. PET/CT readers, have a look. You'll be glad you did.

Disclosure statement: The folks at MIM gave me a UniBall pen, worth approximately $1.

I Have GOT To Have This!!!

The definition of "killer app" is different for everyone, but to me, it signifies a piece of software that is so good, you have to go out and buy it (and the platform it runs on if you don't already have that) yesterday.

MIMVista, creater of advanced imaging software, has produced the MIM iPhone Application, and this is my killer app, my excuse to run right out and buy the new iPhone3G, scheduled for release on July 11.

The MIM iPhone Application provides multi-planar reconstruction of data sets from modalities including CT, PET, MRI and SPECT, as well as multi-modality image fusion. Using the multi-touch interface, users can change image sets and planes; adjust zoom, fusion blending, and window/level; and measure dimensions and SUV.

Lemme at it! Now, my contract with AT&T says I'm due for a new phone sometime in December, but....there are ways, there are ways.

The iPhone3G now uses AT&T's faster 3G system, and has GPS chips built-in.

It's definately prettier than my Blackjack II. Now whether it's actually more functional remains to be seen. Look for my report sometime in July. Or December.

I just received an email response to my query about MIMVista and the iPhone3G. The text follows. There was actually a brochure attached, but I can't open it on this convention computer I'm borrowing....

Q: When can I test drive the MIM application?

A: Apple said it will be releasing the iPhone 3G on July 11th and launching the App Store in "Early July". So, the exact date is unknown. Mobile MIM will only be available through the Apple App Store or iTunes.---------------

Q: What will be the cost of MIM?

A: The first Mobile MIM (for referring physicians & hopefully patients) will release at no cost, free.---------------

Q: What features will be in the first MIM application?

A: The features made available in the free Mobile MIM (for referring physicians) will likely be image display, fusion, blend, window/level, zoom, and a few other items. This release of the free Mobile MIM is not intended for diagnostic purposes.---------------

Q: What about the measure mode and other features I see on the internet?

A: Another fully featured MIM application is in the pipeline and will be released Q4 2008.---------------

Q: What about security and HIPAA?

A: To ensure patient privacy, all communications between the Mobile MIM and the MIM Workstation/Server software will be transmitted over a secure encrypted connection. The MIM application will also make use of password locks, tamper-prevention features and will encrypt the patient data on the iPhone / iPod touch.---------------

Q: Will MIM support DICOM Query/Retrieve or DICOM Send?

A: No, we do not plan on implementing this for two reasons: Security & Simplicity.---------------

Q: How does patient data get onto my device?

A: Patients are transfered from a MIM Workstation and/or Server.---------------

Q: What if I do not have the MIM Workstation / Server Software?

A: You will need to buy or demo the MIM Workstation / Server Software. For the time being, only sites that have MIM Workstation/Server software can send data to a iPhone / iPod touch. The free Mobile MIM will install on the iPhone & iPod touch with 1 or 2 pre-loaded patients, so users can experience the Mobile MIM application.---------------

Q: What happens next? and who will contact me?

A: All feedback has been assigned to a sales rep and/or engineer at MIMvista. Mobile MIM should be on the App Store when it is launched by Apple. Please contact us with any questions.-- The MIMvista Team

I'm currently in New Orleans getting some SNM....that's the Society of Nuclear Medicine, perverts! No doubt MIMVista has a booth here. I'll report more tomorrow.

Following The Green Brick Road Yet?

I'm getting a lot of traffic from BDM Information Systems, the software arm of GE, looking particularly at my posts on the Centricity/Dynamic Imaging upgrade paths. I'm glad to be of service to all my friends at GE. Let me know if there is anything else you guys might need!

More PACS Ownership Follies

On the heels of the last post comes an interesting incident illustrative of how the process works.

IT informed the PACS team at 12:26 PM yesterday that there will be a planned internet outage from 2AM through 4AM tomorrow morning, and PACS informed Radiology of this via email at 4:17 PM. Supposedly, services within the enterprise should continue to function (i.e., the LAN's will still be functional), but there will be no outside access. This is a bit of a problem, as we have nighthawk radiologists that sit at one site and read for all of our sites. Scans from other hospitals are piped in via.....Internet!

Yours truly complained (very respectfully, I might add):

As you know, our night radiologists are completely dependent upon the internet connection to the outside which allows them to serve (our outside) hospitals. While we appreciate the advance notice, I hope it is understood that this planned outage represents a significant impact upon our ability to provide patient care. Therefore, I respectfully request that this outage be postponed until such time as (we) can together formulate an alternative conduit to allow for us to provide uninterrupted service.

Your understanding in this matter is greatly appreciated.

PACS responded:

Due to the necessity of this planned system outage, we can not postpone the outage. We understand your concern for patient care, which is why we had hoped that with enough prior notice alternate means of access could be arranged.

Thank you for bringing this to our attention and we will work together to minimize situations like this in the future.

OK, I do hope we can stick to that last sentence. Is 34 hours enough prior notice? I don't think so, personally. But, since IT owns the network, IT triumphs yet again.

Who Owns PACS? . . . and are they Highly Reliable?

Among the many things I missed by not attending SIIM was a discussion on something near and dear to my heart, the "ownership" of PACS. The debate, as summarized by AuntMinnie.com's Cynthia Keen, pitted Dr. Paul Chang, speaking for IT against Dr. David Channin, pushing for Radiology ownership. Dr. Chang argues for a "matrix" to "enable the experience of one domain to be adopted by another domain." And,

Because PACS is the multimedia component of an electronic health record (EHR), the EHR must be optimized to support radiology workflow. Not only is this a complex undertaking, but it logically fits as the responsibility of the IT department -- as long as the IT department has a global vision and a progressive philosophy, Chang said.

Dr. Channin, whose idea of "Napster PACS" I borrowed for my Portable Patients post and article, counters:

"Radiology has led informatics technology innovation in hospitals and will continue to be the source of informatics leadership in healthcare," Channin said. "Domain expertise must take precedence over IT expertise. Tools don't drive domain innovation."

"If controlled in a central manner, such as a matrix structure, the priorities of a radiology department will be subjected to control by an IT department juggling priorities representing multiple domains in a hospital," he said. "If you don't have budgetary control of your bucket of allocated capital dollars, you have lost control. Your critically needed PACS upgrade will be competing with acquisition of a new laser doodad for OR."

Radiology departments should wield the power they have as cash cows for hospitals, define their IT domain borders, provide access to them with standard interfaces, and demand autonomy, according to Channin. He recommended that radiology departments contract with IT departments for "commodity services" such as networks, virtual operating systems, and data storage.

"As progressive as an IT department may be, it doesn't care about the quality of information that radiologists need," Channin said. "Even if a new capital acquisition is approved in February, you may be told that you can't upgrade XYZ until the department synchronizes something else in August. It is imperative that radiology departments be able to control their own domain."

I have to side more with Dr. Channin, and not just because I stole, I mean borrowed, his earlier ideas. As a radiologist, my patients come first. Period. End of story. There should be nothing between me and my patients' images, because it is my job to interpret these images and do my part for patient care. Now, if you will all turn to the Book of Dalai, Chapter 3, Verse 3, you will take reverent note of the first two Laws of PACS:

I. PACS IS the Radiology Department.

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.

Not to toot my own horn (like Bill Clinton does), but I think I figured this out a while back. Nowhere else in the hospital is the most critical piece of equipment farmed out to a different department, and why should this be so for PACS and Radiology? Well, that gets into politics. PACS, after all, is a tangle of wires and computers that we lovingly refer to as networks, servers, and workstations. Amazingly enough, that's what IT deals with, too! Therefore, they want to claim ownership of the PACS package, too. Why do they want to take on more headaches, including middle-of-the-night calls, and blogging radiologists that quote them in embarrasing statements? It's called territory. A department's budget is its club, or its reputation. (I will refrain from using crude, coarse, peurile male anatomic references in this discussion, but you know where I'm going.) The more stuff under their domain, the higher their budget, and the greater the power the department commands. So, it is to IT's advantage to engulf PACS, and they aren't about to let it go.

So what's the problem? Since the IT wonks are supposed to know everything about computers, aren't they the logical masters for PACS? In the discussion that followed the AuntMinnie SIIM recap, AM member Frumious says:

This is going to sound like a rant and in some ways it is. My experience is that with 1 exception, most Hospital's IT, including large ones with large budgets and multiple campuses and connections to remote sites are not exactly bleeding edge and performance and service is adequate at best. They are indifferent to Radiology's needs and generally see the email system as more important than the clinical systems. . .

Also, how many IT departments seek out clinical input or have staff with clinical background in the department at the decision level? And what of accountability? Do you all rely on your IT Dept to quickly respond to your issues, whether troubleshooting and resolution or your needs? My experience is that the Hospital doesn't hold the IT dept in high esteem either. They don't understand that Radiology creates revenue and provides a large add-on service to many different disciplines. . .

How many of you had your PACS selected for you by IT or by Administration because GE or other vendor made them think they got a great discount & the vendor would take care of everything, all without your clinical input?

. . . Paramount is the workflow. Everything else is a tool to improve the workflow. Use tools, don't hire them.

But it goes beyond a mere turf war between radiology and IT, it goes into service & the concept of taking care of the customers. Radiology's customers and concerns are imaging the patients and providing the referring physicians access to the images and results quickly and collecting the revenue to stay in business. Getting IT to understand that concept is usually an uphill battle (go figure). For example, it's often radiology who is "pushing" IT to improve things such as the network because pushing images makes network needs just so much greater; reliability because RIS/PACS and the network are mission-critical. IT sees radiology as too demanding and would prefer to see radiology as just another customer of IT and deal with everyone's needs FIFO.

My personal experience has varied. Much depends on the individual members of IT one works with. I have met some over the years who repeat the mantra over and over, "That won't work, we can't do that, let's have a meeting in six months to decide if we should talk about that later." Most, however, do have an inkling about what is important to keep the department running, and they are certainly our allies in doing so. Not that we haven't had some glitches. I remember the time IT refered all of the rads to the Help-Desk to change passwords after some particular change, and the Help-Desk didn't answer the phone after 10 rings after 5PM because there was only one staffer. Great situation for the nighthawk coming on that night. And we won't even talk about IT-driven PACS selection processes.

A fellow named Mike O'Meara posted his views on the AuntMinnie thread, and I think he's on to something. Mike is president of ORQA, whose mission is to "Reduce risk for ancillary health care services by providing enabling technology to promote a culture of collaboration, open communication, and mindfulness." Um, OK. Well, have a look at their website if you're interested in further information.

Mike suggests a more middle-of-the-road approach for PACS stewardship, one that has great potential. It seems that there is a new bureaucratic or organizational or whatever concept called High Reliability Organization tenets, brought to you by the Agency for Healthcare Research and Quality, a proud member of Health and Human Services, i.e., they are from the Government, and they are here to help you. Now, I don't have the patience to wade through the 40 pages of governmentalese, but the executive summary on page 1 says:

At the core of high reliability organizations are five key concepts, which we believe are essential for any improvement initiative to succeed:

Sensitivity to operations. Preserving a constant awareness by leaders and staff of the state of the systems and processes that affect patient care. This awareness is key to noting risks and preventing them.

Reluctance to simplify. Simple processes are good, but simplistic explanations for why things work or fail are risky. Avoiding overly simple explanations of failure (unqualified staff, inadequate training, communication failure, etc.) is essential to understanding the true reasons why patients are placed at risk.

Preoccupation with failure. When near-misses occur, these are viewed as evidence of systems that should be improved to reduce potential harm to patients. Rather than viewing near-misses as proof that the system has effective safeguards, they are viewed as symptomatic of areas in need of more attention.

Deference to expertise. If leaders and supervisors are not willing to listen and respond to the insights of staff who know how processes really work and the risks patients really face, you will not have a culture in which high reliability is possible.

Resilience. Leaders and staff need to be trained and prepared to know how to respond when system failures do occur.

How does this bureau-speak fit in? Mike thinks they will

. . . hopefully create a culture where the organization as a whole has "ownership", but different stakeholders in their area of expertise have the accountability for the success of PACS. The IT folks should accountable for ensuring the Imaging IT systems (PACS, RIS, VR, etc) are available as close to 100% of the time as possible, and work to remove all techological barriers to successful operation of the system.

The clinical folks should be accountable to ensure the workflow meets their needs and that the system is used to its full potential.

The business managers in radiology and administration need to be accountable for quantifying how they will realize a return on their investment in PACS.

The goals of each domain inherently contradict each other and it's up to the collective team to compromise on solutions that work for everyone. In most truly successful PACS implementations I've come across, a formal team consisting of stakeholders from each domain of expertise is who "owns" PACS, and that team is held accountable to the CXO/Board of Directors of the organization. If hospital politics or hidden agendas prevent the formation of an effective cross-functional team, then there are much deeper organizational issues than "who owns PACS"...

Frankly, I like it. The High Reliability factor for this purpose will definately be the Sensitivity to Operation thing. Everyone has to realize the mission-criticality of PACS. That's just the way it is. Emergent patient care trumps everything else. However, the key problem, as Mike points out, is that indeed some of the goals of each department might conflict with those of the other divisions. Then you get into a urinating contest which is often won by the folks with the greatest political clout. But that isn't how it has to be. There has to be compromise between the departments, but not of the ultimate goal, which is using the PACS system, that IS the department, to further patient care. The minute that gets disrupted, heads need to roll until those that are left understand the mission.

If I had my own way, PACS would be completely under Radiology's domain. However, we have to be practical, and not reinvent the wheel. It makes much more sense to utilize the hospital network rather than install a second LAN in our department, and so forth. But it all works if and only if everyone cooperates, and understands who really runs the show. Which is me, of course. Funny how every member of the team seems to think that of themselves as well.

A Clock For The Industrious

From Yugo Nakamura:


Many thanks to the One and Holy PACSMan! (I gave him a promotion!)

PACS Synergy Takes Energy

My fellow author Erik Ridley (OK, Erik, you can stop laughing now) reports today on AuntMinnie.com about the use of Synergy, an open-sourch program from SourceForge, to control multiple PACS apps from one computer. This was based on a SIIM presentation by Stuart Pomerantz, M.D., from Mass General.

"Many of the ergonomic benefits of a 'one-box' radiology solution can thus be achieved in a multi-PC environment with keyboard-monitor software at no additional cost," Pomerantz said. He discussed the MGH researchers' experience with an open-source, virtual "one-box" system during a scientific session at the meeting.

A "one-box" approach with all applications running on one workstation would offer ergonomic advantages, allowing users to use a single PC (and keyboard and mouse) to drive all applications, he said. A virtual, network-based "one-box" model would also have this benefit, yet it would retain the flexibility to split into two separate simultaneous input modes for two-person navigation and data entry, according to Pomerantz.

"It's important that the virtual 'one-box' is not through a switching device, through a manual switch where one keyboard and mouse controls a different on-screen connection to one PC or the other, but rather a fluid connection across all PCs with simultaneous control," he said.

This is an interesting idea, and actually one I have encountered before. One of my partners bought a second computer, and connected it to the same monitor, mouse, and keyboard as his first computer via a hardware KVM switch. He did this to allow different (and at that time somewhat incompatible) PACS clients
to run on the different computers, but to still be controlled from the same perch in his office. Personally, I thought it was overkill for the purpose.

Pomerantz's approach does not use hardware KVM switches, but rather networks control via the Synergy program.

With synergy, all the computers on your desktop form a single virtual screen. You use the mouse and keyboard of only one of the computers while you use all of the monitors on all of the computers. You tell synergy how many screens you have and their positions relative to one another. Synergy then detects when the mouse moves off the edge of a screen and jumps it instantly to the neighboring screen. The keyboard works normally on each screen; input goes to whichever screen has the cursor.

In this example, the user is moving the mouse from left to right. When the cursor reaches the right edge of the left screen it jumps instantly to the left edge of the right screen.

OK, this has potential, but for many of us, the potential is that of confusion. I would be rather concerned about realizing which computer it is that I'm operating.

Is this all really necessary? I'm not so sure of that either. Most desktop workstations have the horsepower to drive the PACS client, SR window (if you are so unfortunate as to need one), RIS client, and some level of advanced visualization software. If you are using an integrated thin client, there is relatively little impact on your CPU.

I'll probably try this at home, and amuse my wife and son no end as I scoot my cursor over to their screens while they are trying to do something productive. I might have a different opinion of the efficacy of using this with PACS if I were to see it in action at Mass General, but short of that, this seems to represent about the same level of overkill as the old KVM switch idea. Just my humble opinion, of course.