If You Can't Beat 'Em...

Another Question

Hypothetical question:

Which vendor/product out there is capable of (rapidly) overlaying an existing PACS?

So far, Merge, Intelerad, and Visage seem to be able to do so. Any others? Any experience in doing this?

And how well will they work if your networks aren't in good shape?






Thank you for sharing your thoughts.

A Question For You...

A very simple question...

Has this blog been helpful to you? Has the description of our trials, tribulations, and occasional successes with PACS led you astray or in the right direction?

Just wondering...

Connectivity Deja Vu

Tonight, there was semi-emergent IMPAX downtime to allow for the updating of the Connectivity Manager. The 6-8 hour anticipated impact on PACS was planned about 8 hours before it happened, and is necessitated by our imminent move to IMPAX 6.6.1. The system is due back up in less than one hour, and we'll see if we fare any better than last time. You see, this is all quite familiar. Here is a regurgitation of my post, "Connectivity Banisher" from January, 2009:

-----------------------------------------------------------------------------

In the world of Agfa Impax, a "Connectivity Manager" is:

. . . a middleware component in the integration between HIS, RIS, modalities, and PACS systems, linking patient and study data with images. To display the information available from a non-Agfa RIS in the Text area of IMPAX, connect to the Connectivity Manager. . .

The main purpose of the Connectivity Manager is to take data from one system, such as a HIS, and translate it into a format that another system, such as a modality, can understand. Connectivity Manager accomplishes this translation with mappings. The mappings tell Connectivity Manager how to translate incoming and outgoing messages to external systems. The following mappings must be configured so that Connectivity Manager knows which report source to go to for each study, and how to translate messages sent from IMPAX. . .

Map a reporting name into the Data Store by identifying the sending facility in the Connectivity Manager database. Identifying this value means it will work regardless of whether the sending facility sends their name along with the message or not. Also, if the sending facility changes their name at some point, mapping or configuration changes will not be necessary. The Default Assigning Authority identified in this mapping is the name of the report source entered in the Business Services Configuration Tool.

The sending facility is required to view reports in IMPAX. Connectivity Manager uses the Entering_organization and Requesting_Service mappings to populate the sending facility field. These mappings should include the Default Assigning Authority so that every report contains a sending facility.

Our Connectivity Manager was upgraded last night. And again this morning. From the rad's point of view, this means:

During this time Modality Worklists will not be available and Technologists will have to manually input ALL Patient Information. Studies sent to IMPAX will Fail Verification, and will not update with Reports until the downtime is ended.

I drew the short straw, and experienced the joys of the upgrade. Fortunately, the downtime lasted less than one hour, and not two. Of course, only a few of the techs got around to manually inputting ANY Patient Information. Still, we were OK. Until this morning, when this information (including the accession number by which we dictate) was suddenly absent once again. The culprit was, of course, the Connectivity Manager, which seemed to be confused by "multiple" inputs for the same patient. Now that's a problem, which we hope will be fixed by the experts before too much longer.

As usual, Dalai's Laws of PACS apply. In particular, the First and Third Laws are applicable:

I. PACS IS the Radiology Department.
III. Once PACS, never back.

When PACS malfunctions, the department malfunctions, and don't even consider asking anyone to go back to a manual process. It ain't gonna happen.

So, in the ideal land of Dalai-wood (Hooray for Dalai-wood!), PACS should never break. Since that isn't achievable, these thing need to be created with an eye toward simplicity and functionality. Based on what the "Connectivity Manager" is supposed to accomplish, I'm not really certain why it has to be a separate program or computer or whatever it is. Shouldn't the simple, basic, core PACS be able to talk to others? OK, provide a look-up table (user-configurable, of course), but do we have to have a big, separate, grandiose module that manages to bollux up the works when we upgrade it?

Yes, I know..."simple" and "basic" aren't in the vocabulary of a lot of PACS vendors. Neither is "easy". And "uptime" can be defined to the preferences of those making the definition. But as far as I'm concerned, if it isn't totally "up," then it's "down." (Which happens to be true for many things in life.) So, today, we were "down," courtesy of our dear Connectivity Manager.

---------------------------------------------------------------------

A party close to the 2009 update had this closing comment:

Please understand this is not normal hospital type workflow, and with the hundreds of other mappings to get right is an easy oversight, the missing "Cerner ID" should have been noticed during your sites testing and identified prior to the go live.

But once again an easy oversight by all involved.

This also was not a standard upgrade, Yes your CM software was upgraded to the latest version, But behind the scenes each and every interface was recreated from scratch, including the HL7 Feeds, all the modality’s (100’s) and each and every Impax device and client, There was months of work evolved with this upgrade.

On a different note, I truly enjoyed reading your blog, And can fully understand the frustration these upgrades cause the people working with the software. I do try my best to ensure as little impact to your job as possible.

I have yet to understand what, beyond me, makes our system any different than any other. And I'm not sure how we were able to squeeze "months" of work into 14 hours. Perhaps the process has been perfected in the last 6.5 years. Right.

----------------------------

ADDENDUM

Initially, the update seemed to have gone well, and I even sent an email congratulating those involved. WRONG.

It apparently did NOT go well. In the middle of it things went completely down for about 30 minutes. No PACS, no nuthin'. Did we have adequate communications on this? Did we share the responsibility properly?

And our 6.6.x upgrade has been inexplicably delayed.

Not good. Not good at all.

Turning Point?

Image courtesy thisfabtrek.com

There was a meeting involving everyone with a stake in our PACS problem. This included radiologists, IT folks, administrators, and representatives from the vendor. The purpose of the meeting was to outline where we were, where we are, and where we are going. I left the meeting feeling cautiously optimistic for the first time in quite a while.

I'll not delve into specifics much, as they probably won't help you with your PACS problems, nor will they help you help me with mine. The generalities however, should prove more valuable.

The bottom line is quite simple, really. Our problems stem in greatest part from lack of communication. This gap occurred primarily between IT and the vendor, but there was also a rather large chasm between the radiologist end-users and the other two entities. Let's talk about that one first.

As an electrical engineer, I'm well-versed in the concept of the feedback loop, particularly the need in a circuit for negative feedback:

You've all heard the screeching "feedback" from a public-address system going out of control. Most amplifiers have a negative feedback loop, illustrated by the wire above using some of the output of the amplifier to "tone down" the input. So it is with life in general. If you think you are doing everything properly, and you receive no negative modulation, you will keep doing the same thing whether or not your actions are correct.

We rads had (or more honestly, exercised) only limited feedback options when it came to PACS. We the rads never really put our heads together to create a grievance list. Yes, one rad here or there would get upset with slow speeds, workstation crashes, slow scrolling, etc. Sometimes these could be fixed by the PACS administrators, sometimes only marginally improved. Someone would get a personal profile remade, although we never learned why this would help, someone would get his worklists redone. And so it went. In this way, little problems propagated into big problems.

I'll take some level of personal responsibility. I was so, well, jaded may not be the word...disheartened? Complacent? Resigned? Well, I had more or less decided that nothing would change until we had a major upgrade, whenever that might be, and I found ways to tolerate the glitches. It took two of my former partners, now bosses, who recently started working nights, to say "ENOUGH!" The minor slow-downs become quite major when you're trying to pump out dozens and dozens of studies through the wee hours of the morning. To be fair, there was further deterioration of the system during their initiation into the dark side (I mean dark hours), to the point that the workstations crashed, and ultimately there were a number of system outages, which certainly brought the whole situation to a head. The newly-minted night-stalkers began the campaign that has brought us to the brink of...a solution.

Communication is paramount as always, and we've made some great strides in that realm. First, we insisted on having a call-team from both IT and the vendor. We were briefly relegated to the "Help" desk; when they actually answered, they were little more than a rather slow answering service for IT. Second, we streamlined the process for rads to report problems directly. This was prompted by a response to a complaint implying that no one had ever mentioned the problem before. When Donald Trump's cell phone number was published, instead of having a little hissy-fit as we saw with a certain Senator, Trump simply put a campaign ad on his line. This inspired us to create an email thread wherein any and all PACS complaints could be reported directly to the right people. And report we did. Initially, there were tens of emails per day; this has tapered off to only one or two. We have definitely made progress.

While we physicians can be quite problematic, the deeper institutional snafus lie with IT, the vendor, and their somewhat dysfunctional relationship. There will be yet another meeting to more precisely define just how that relationship will progress, and while I detest meetings, that is one that should have been held years ago. You see, there really wasn't a single point of failure, but there were quite a few, shall we say, lost opportunities for improvement.

It turns out that one of our major outages was a network problem, caused by an update push that got out of hand. Another slow-down was the result of the EMR grabbing too much bandwidth. There was a bug in a NetApp image server that took us down. OK, we assume these things happen and can be fixed.

But it took a village full of angry radiologists to bring to light that yearly service on some of the servers might not do the trick, particularly when a couple of the critical servers running SunOS/Solaris weren't touched at all. The latter had been running on an elderly version of the OS, and had a bug that was fixed umpteen versions ago. Update the OS, kill the bug. And here is where we had trouble. Putting it simply, everyone assumed the other entity was going to take care of stuff like this, if they assumed anything at all about it. And so nothing happened until the recent unpleasantness.

We found that hardware was sometimes purchased without consulting the vendor, and then retrofitted with the vendor's help when it wasn't quite right. Perhaps both parties could be a little more proactive here, so we can all ask for permission instead of forgiveness.

Computers are made by imperfect human beings, and are thus imperfect themselves. To assume otherwise is naive at best. And so in a mission-critical area such as PACS, one must be ready for the inevitable glitch. There has to be a downtime plan, and an out-and-out disaster recovery solution. Guess what? We have neither. To my knowledge, the downtime plan hasn't been changed since I spoke at RANZCR in Perth in 2010: after four hours of outage, we start printing to film. Unfortunately, we no longer have any film printers. The next best thing, which we have been having to do, is to read directly from the modality's monitor. It isn't optimal, but it works, sort of. As for a full-fledged disaster, data is stored offsite as required. But it's on tape and recovering might take a very long time. If we could muster the resources. Let's hope it doesn't happen.

PACS, as it turns out, is the only Tier One service that does NOT have a proper downtime solution. Why did we get left out? Money. It was hard to justify a complete, mirrored, automatic fail-over that would only be used a small fraction of the time. Unless you happen to be a trauma patient in the Emergency Department, where life-and-death decisions are put on hold while someone fiddles with the server. Then it seems perfectly justified.

In the end, we all serve one customer, and that is YOU, the patient. Everything we do in this business, every decision we make, every scrap of hardware and line of code we purchase and use is meant to promote your health and well-being. It was said by some that we radiologists were "paying the price" for the various challenges I've outlined. That's true to some extent, but the real victims, at least potentially, are the patients, and that CANNOT be allowed to happen.

I've been blogging about PACS for almost 11 years, and my basic message hasn't really changed much. PACS IS the Radiology Department, and the hospital cannot function without it. Making this all work, and work properly, is in huge part a matter of communication. You have seen what happens when the discourse fails or doesn't happen at all. The downtime plan, or lack thereof, illustrates what happens when one of the groups involved in PACS, the rads, becomes disenfranchised with respect to the decision process. One of us could have very easily convinced the powers that be that we cannot tolerate a four-hour gap in service. We weren't asked to do so; we didn't even know the question had been posed. Now we do. And I am cautiously optimistic that this will improve, as will the rest of our experience.

I would be remiss if I didn't take the opportunity to excoriate the majority of PACS and EMR vendors while I'm on this particular rant. You are still not making user-friendly software. We all know it. PACS is bad enough, but our EMR and its CPOE (Computerized Physician Order Entry) is so very poorly written and implemented as to drive a good number of physicians into early retirement. Seriously. This garbage is served up as caviar to, and purchased by, those who DON'T HAVE TO USE IT, and again the physicians are disenfranchised. This too will negatively impact patient care, and it CANNOT, well, it SHOULD NOT be allowed to happen. But it is.

Let's have a meeting about THAT, shall we?

And Another New Pres For TR

Looks like TeraRecon has a new CEO:

(from radiologybusiness.com)

TeraRecon, a global medical image management company, announced that Jeff Sorenson is the company’s new president.

Sorenson has been with TeraRecon since 2004. His most recent position with the company was senior vice president of sales and marketing.

“TeraRecon is unique because it offers a complete and truly vendor-neutral 3D advanced visualization suite which can be extended to serve the medical image viewing needs of the entire health enterprise," Sorenson said in a statement. “I am excited to serve our valued customers and to drive innovation in this new capacity as president.”

Meanwhile, Venkatraman Lakshminarayan has stepped down as CEO and CFO. Lakshminarayan had been TeraRecon’s CFO since 2005 and its CEO since 2014.

TeraRecon also reported that a successful August has led to an increase in iNteract+ interoperability and enterprise image-enablement projects.

As a (hopefully) valued customer, I'm looking forward to working with Mr. Sorenson as well as Fred and the rest of the gang. Congrats!

A Post For Larry

My friend and colleague Larry tells me he has become an avid reader of the blog, so this one's for you!

For the record, I'm discussing our situation in this public manner in hopes of eliciting help from those who are smarter than I am, with more experience than I have, and who might actually have a clue about what is going on with our PACS and how to fix it. I believe this if anything REQUIRES discussion about a situation that is IMPAIRING PATIENT CARE. I have tremendous respect for privacy and security, and I will do nothing to compromise it. But as Mr. Spock might have put it, the needs of the many outweigh the needs of the few, and the need of the patients, and those of the physicians to care for their patients, outweigh everything. That is why the hospital exists, it is why the Radiology department exists, it is why IT and the vendors exist. Period. 

But back to Larry. He and other colleagues have been gathering interesting images from our PACS, some of which are reproduced below:

If we cannot show the patient, I guess we can all go have a three-martini lunch, since there's nothing else for us to do. Ha ha. 

This would all be funny if PACS was the conduit for Netflix or something equally frivolous. As our episodes of outage and electronic impairment (no, we didn't have a three-martini lunch!) demonstrate, there is a severe and immediate NEGATIVE impact on patient care, and we have to get a handle on it NOW. The good news is that we are really starting to see improvement. It's sad that we had to have a total meltdown of personnel and machinery for that to happen, but that's the way it is.

From the outside, and from rather minimal information often fed to me third-hand, I am not really seeing a concentrated, orchestrated effort to get to the bottom of this, but rather a lot of shot-gunning that has had little impact overall. Yes, we've seen some improvements, but clearly, we are far from fixed. (There are those out there who would like to get ME fixed, but we won't talk about that.)

I'm seeing three distinct but likely related problems.

1. General slowness of the system, which varies by site. Transmission tests I have managed to see show this variation. This must have something to do with the network. It was suggested early on to see if the client behaves properly on a station connected directly to the server. Has this been done? Connecting via the Internet outside of the enterprise yields good service. That's a big clue!

2. Client software and hardware crashes. Is this a software problem? If so, is it a problem with the local client, the server, both? Could it relate to the network? Is it a Windows 7 problem? The clues are all there.

3. Slow searches. This seems to relate to corrupt profiles. I discussed this with PACS people, and I'm told that the user profile is simply an XML file, just a list of parameters that tells the client how the particular user wants things arranged, etc. Supposedly, logging on to two or more workstations simultaneously corrupts the profile. So, rather than spend hours creating a new but still fragile profile, how about someone figure out why IMPAX is even capable of corrupting the old one? We simply don't have time to rebuild profiles during a hectic workday, and I'm not going to waste everyone's time doing so when we don't even know why it helps or whether the change will stick. And if logging on twice can create a patient-care-impacting situation, perhaps a hot-fix needs to be implemented to prevent this practice, and the FDA notified of such.

There is an interesting, illustrative little side show to tell you about. I heard third-hand that some were questioning if my little AutoHotKey script for keeping the RIS window active might be the source of some or all of our problems. The turn-around-time (TAT) of the final report is a very important metric for patient care, and of course quicker delivery of the report is obviously helpful. Our performance in this regard is tracked, and all of these factors led to my creation of the little macro that could...keep the RIS window open and keep reminding us to sign our reports. As it turns out, though, my little bitty AutoHotKey macro apparently became quite the topic of discussion. IT security got very upset at its very presence, calling it all sorts of nasty names, and apparently a few were directed at me personally. The punch-line, though, is that the use of the macro was APPROVED by that department in 2010, with the only reservation being that someone could conceivably use AutoHotKeys to create a script which would bypass the need for a password. Given that I'm the only one who knows how to do it, and I'm not about to create something like that, we should be OK. Fortunately, most of my colleagues have made it past the days of inscribing the password on the bezel of the monitor with a wax crayon.

Being a cantankerous, semi-retired, cranky old lout, I will simply note that this episode demonstrates how things don't get accomplished.  Accusations fly, fingers are pointed, and some of the real issues don't get the attention they deserve. It would have taken literally 2 minutes to go to a station where this complied script is running, and activate Task-Manager to see exactly how many resources are being utilized. But I saved everyone the trouble. I've run task-manager (on those machines which don't have it and right-click disabled) and found minimal impact. (In addition, it shows that IMPAX is in a non-responsive state during some of those hour-glass generating waits. There's another clue for you. Anyone notice this before?)

To prove my point on the machine I was using at the time, I had to use Microsoft's Process Explorer, as it was felt too dangerous to allow radiologists access to Task Manager on some machines. Here's the result for my little script NewSigner3.exe:

The compiled script NewSigner3.exe utilizes 0.04% of CPU time on the IMPAX client workstation

Yup. Wasting 0.04% of CPU time could have devastating effects.

Once I made these results available, I was told: "Oh, no one was thinking that the script itself was the problem; but it keeps the  RIS window open, and that's what's wrong!" But like a bunch of Greek philosophers of old, sitting around the Parthenon contemplating how many teeth a horse should have, rather than actually finding a horse and counting its teeth, no one checked this. So I did:

Citrix window executables for RIS window use 0.15% of CPU time

Oh, but it turns out that wasn't what was being considered either. No, it seems that the fact that the RIS window was being clicked automatically every 20 minutes or so to keep it active and to remind us to sign our reports "creates downstream problems in that it allows for people to be logged in on multiple stations." (See discussion about profiles, multiple logons, and XML files above.) Someone please help me understand how keeping the RIS window open has any effect on the PACS. It seems pretty clear that some folks in the loop haven't tried to understand just what this little script accomplishes, and maybe somehow think it tweaks the PACS client. But it doesn't, as would have been discovered with 30 seconds of effort. Or a 30-second phone call to me.

You would think I had attempted to unleash the worst virus in existence upon the network.

Anyway. I did say above that some progress had been made, which is true, and some of the problems have been identified. Eventually, some of those will be fixed, too. One server had not been updated in a long time and it was delaying arrival of prior studies. No, I don't know why it wasn't updated. Very large individual disks had been used for storage which might have been beyond the recommended size. I don't know how that happened either.

You might recall me saying something about image skipping or rotten scrolling performance if the annotations were on. Apparently, this relates to the five-year-old version of software we are using, and should resolve once we upgrade.

Progress is progress, however slowly it might, well, progress. Perhaps we can Git 'R Fixed sometime soon. Larry? 

MGH Still Uses Old AMICAS!

Look familiar? This is a screen-shot from AMICAS PACS, circa 2005. That would be about 10 years ago.

But I just had a flash of deja vu...While watching tonight's episode of Save My Life on ABC, filmed at Mass General, I very briefly spotted a PACS client of this vintage...Here is the screen-shot (actually taken from last week's episode...yes, that is a severed hand, which was successfully reattached):

I knew AMICAS PACS had been used as an overlay to IMPAX at MGH, put in place back when IMPAX couldn't handle multi-slice scans.

Apparently, a 10-year-old AMICAS system is good enough for Mass General. Maybe that's because after 10 years, it still works. Unlike, well, need I say it?

Error Message

I'm just waiting for this to happen...

And We're STILL Not There Yet

Despite rosy, glowingly positive reports from IT and Agfa, implying that all is well and the rads are once again fat and happy, we continue to have difficulties.

This morning, my poor, suffering bosses (formerly partners) who were on Saturday call report this amusing scenario:

Now at hospital for over one hour. Still unable to read studies. Worklist now opens in the upper left screen about the size of a postage stamp. I am able to expand it to the size of the screen. Worklist however does NOT open studies to be viewed; in another words, we see no images, just a worklist. And I have done the usual reboot four times on four different computers.

You'll be glad to know that this glitch, which affected all three guys on call, was finally fixed by bouncing all three production servers. How long that will keep things going, I haven't a clue.

To be fair, much has improved, with speed improvements at most sites. I find I no longer have to turn off annotations to scroll through a CT series, which is huge. But we are clearly not out of the electronic woods as yet.

I am told that the improvements have come because of various maintenance procedures, cleaning out this, redoing that, etc., etc.  You might ask, why weren't these things done before the radiologists started acting out? That, dear reader, is a VERY good question...

IBM BUYS MERGE!!!"Merge! Come Here! Watson Needs You!!"

NEWS FLASH!!!

I just received the notice (as did several thousand others) from Justin Dearborn, Merge CEO, that IBM has purchased Merge, and will incorporate it into the IBM Watson Health Unit. Here is the press release:

Chicago, IL, 06 Aug 2015

Armonk, NY and CHICAGO -- [August 6, 2015]: IBM (NYSE: IBM) today announced that Watson will gain the ability to “see” by bringing together Watson’s advanced image analytics and cognitive capabilities with data and images obtained from Merge Healthcare Incorporated’s (NASDAQ: MRGE) medical imaging management platform. IBM plans to acquire Merge, a leading provider of medical image handling and processing, interoperability and clinical systems designed to advance healthcare quality and efficiency, in an effort to unlock the value of medical images to help physicians make better patient care decisions.

Merge’s technology platforms are used at more than 7,500 U.S. healthcare sites, as well as most of the world’s leading clinical research institutes and pharmaceutical firms to manage a growing body of medical images. The vision is that these organizations could use the Watson Health Cloud to surface new insights from a consolidated, patient-centric view of current and historical images, electronic health records, data from wearable devices and other related medical data, in a HIPAA-enabled environment.

Under terms of the transaction, Merge shareholders would receive $7.13 per share in cash, for a total transaction value of $1 billion. The closing of the transaction is subject to regulatory review, Merge shareholder approval, and other customary closing conditions, and is anticipated to occur later this year. It is IBM’s third major health-related acquisition – and the largest – since launching its Watson Health unit in April, following Phytel (population health) and Explorys (cloud based healthcare intelligence).

“As a proven leader in delivering healthcare solutions for over 20 years, Merge is a tremendous addition to the Watson Health platform. Healthcare will be one of IBM’s biggest growth areas over the next 10 years, which is why we are making a major investment to drive industry transformation and to facilitate a higher quality of care,” said John Kelly, senior vice president, IBM Research and Solutions Portfolio. “Watson’s powerful cognitive and analytic capabilities, coupled with those from Merge and our other major strategic acquisitions, position IBM to partner with healthcare providers, research institutions, biomedical companies, insurers and other organizations committed to changing the very nature of health and healthcare in the 21st century. Giving Watson ‘eyes’ on medical images unlocks entirely new possibilities for the industry.”

Teaching Watson to “See” Medical Images
The planned acquisition bolsters IBM’s strategy to add rich image analytics with deep learning to the Watson Health platform – in effect, advancing Watson beyond natural language and giving it the ability to “see.” Medical images are by far the largest and fastest-growing data source in the healthcare industry and perhaps the world – IBM researchers estimate that they account for at least 90% of all medical data today – but they also present challenges that need to be addressed:

The volume of medical images can be overwhelming to even the most sophisticated specialists – radiologists in some hospital emergency rooms are presented with as many as 100,000 images a day.

Tools to help clinicians extract insights from medical images remain very limited, requiring most analysis to be done manually.

At a time when the most powerful insights come at the intersection of diverse data sets (medical records, lab tests, genomics, etc.), medical images remain largely disconnected from mainstream health information.

IBM plans to leverage the Watson Health Cloud to analyze and cross-reference medical images against a deep trove of lab results, electronic health records, genomic tests, clinical studies and other health-related data sources, already representing 315 billion data points and 90 million unique records. Merge’s clients could compare new medical images with a patient’s image history as well as populations of similar patients to detect changes and anomalies. Insights generated by Watson could then help healthcare providers in fields including radiology, cardiology, orthopedics and ophthalmology to pursue more personalized approaches to diagnosis, treatment and monitoring of patients.

Cutting-edge image analytics projects underway in IBM Research’s global labs suggest additional areas where progress can be made. They include teaching Watson to filter clinical and diagnostic imaging information to help clinicians identify anomalies and form recommendations, which could help reduce physician viewing loads and increase physician effectiveness.

“As Watson evolves, we are tackling more complex and meaningful problems by constantly evaluating bigger and more challenging data sets,” Kelly said. “Medical images are some of the most complicated data sets imaginable, and there is perhaps no more important area in which researchers can apply machine learning and cognitive computing. That’s the real promise of cognitive computing and its artificial intelligence components – helping to make us healthier and to improve the quality of our lives.”

Watson Health and Merge Capabilities Will Benefit Researchers, Clinicians and Individuals
IBM’s Watson Health unit plans to bring together Merge’s product and solution offerings with existing expertise in cognitive computing, population health, and cloud-based healthcare intelligence offerings to:

Offer researchers insights to aid clinical trial design, monitoring and evaluation;

Help clinicians to efficiently identify options for the diagnosis, treatment and monitoring a broad array of health conditions such as cancer, stroke and heart disease;
Enable providers and payers to integrate and optimize patient engagement in alignment with meaningful use and value-based care guidelines;

Support researchers and healthcare professionals as they advance the emerging discipline of population health, which aims to optimize an individual’s care by identifying trends in large numbers of people with similar health status.

“Merge is widely recognized for delivering market leading imaging workflow and electronic data capture solutions,” said Justin Dearborn, chief executive officer, Merge. “Today’s announcement is an exciting step forward for our employees and clients. Becoming a part of IBM will allow us to expand our global scale and deliver added value and insight to our clients through Watson’s advanced analytic and cognitive computing capabilities.”

“Combining Merge’s leading medical imaging solutions with the world-class machine learning and analytics capabilities of IBM’s Watson Health is the future of healthcare technology,” said Michael W. Ferro, Jr., Merge’s chairman. “Merge’s leading technology and proven expertise represent a unique combination of assets that will deliver unparalleled value to Watson Health clients. Together, we will unlock unprecedented new opportunities to improve patient diagnostics and deliver enhanced care.”

Interesting. Justin goes on to add a personal note:

We are very pleased to share some exciting news with you. Earlier today we announced that we have entered into a definitive agreement under which IBM will acquire Merge Healthcare. Through this transaction, Merge will become part of the IBM Watson Health unit. The plan is for the Merge management team to remain in place following closing. You may read the full press release here, but allow me to take this opportunity to tell you about the news directly and what it means for you.

Combining our strengths as a leader in healthcare imaging with IBM’s powerful Watson Health Cloud cognitive and analytic capabilities will enable us to expand the reach and effectiveness of our solutions. The vision is that healthcare organizations could use the Watson Health Cloud to surface new insights from a consolidated, patient-centric view of current and historical images, electronic health records, data from wearable devices and other related medical data, in a HIPAA-enabled environment.

Additionally, we expect to benefit from the ample resources IBM can offer to support the continued growth and development of our business. In short, as a result of this transaction, Merge products will only become better and you will benefit from continued innovation to support your medical imaging needs.

I want to assure you that you can continue to expect the same level of service that you have come to rely on from Merge. Importantly, IBM will continue to support the Merge platform, and will continue to honor all existing contracts and agreements.

While we are very excited about today’s news, this announcement is just the first step in the process. The transaction is subject to regulatory review and shareholder approval. Until the transaction closes, which we expect will be later this year, we will remain an independent company, and it is business as usual. We remain focused, as we always have, on execution and results, and will continue to deliver the innovation and support that you have come to expect from us.

We’ll stay in touch as future developments take place, and we look forward to continuing to serve you.

Please do not hesitate to contact your Merge account manager with any questions.

What does this mean for us end users? Probably not much difference in service for the immediate future. But this does boost Merge significantly, now putting it up there with the other "big companies". Moreover, IBM does not have the previous stake that those others have with existing PACS software, etc., that has to be taken into consideration when moving forward.

This will prove interesting. I do recall Mike Ferro declaring that Merge would become the premier HIT company, and would eventually be worth $1 Billion. Looks like they made it.

Of course, now we have to worry that Watson will put us out of our jobs, but I'm not expecting that to happen for quite a while.

I wonder when Apple will take the plunge into the HIT pool. Between you and me, I was hoping Apple would be the suitor...

Continued....

On Aunt Minnie, David Clunie asks about how Watson is going to get his electronic hands on the image data floating about the Merge systems. Good question.

I'll have to review my contract with Merge, but I doubt they have unfettered access to the images I store on my own SAN's. But for better or worse, the precedent for sharing ALL of your data has been established for the government at least by Meaningful (Ab)Use, which boils down to having the ability to transmit anonymized (ha ha ha) patient data to Washington.

IBM's somewhat nebulous goal is to teach Watson to "see", which I think Eliot Siegel, M.D., of the University of Maryland, has been doing anyway, and he's probably teaching it much better habits than I would. So acquiring Merge, an HIT/PACS/Cloud Storage company, would necessarily be all about connecting Watson with a very, very large database of images. I don't see any other reason for this purchase on IBM's part.

I still don't have much trepidation about Watson taking over my job, although I'm retiring soon anyway. Looking at the success of the driverless cars, and the problems they are having, tells me that my time line assessments aren't too far off. Driving a car is in many ways a much simpler problem to solve, in no small part because it is a 2D proposition rather than 3D.

In the short run, this purchase gives Merge complete solidity. There will be no more squawks of Merge being a small company whose future is uncertain. Will we Merge users see any huge boon in our day-to-day work? Probably not for quite a while.

I am anxious to get my chance to talk to Watson, though. I'm sure he has the answers to all of my questions. We'll start with "What is the meaning of life?" If the answer is "42", I'll have a complete meltdown.
 

We're Not There Yet

GE might think I've given up on bashing their flagship Universal Disappointment. Sorry, but I've just put that on hold while struggling with Agfa at the other site. More on that in a moment.

I can tell you that some of our Universal problems have been solved, mostly anyway. We figured out that the disappearing measurements were there all the time; we had applied them to a cloned window, and there they stayed, not applying to the original dataset. Who knew? But our other maladies go untreated.

The PET displays still don't work right, and we've heard nothing about the future of this promised function. The Navigator window still hides when we need it. The leveraging of Windows and Internet Explorer to show patient lists and so on needs some more leveraging. But the worst of the errors remains with us:

THIS is what we see when scrolling to the fourth or fifth slice on almost every CT. It will go away...after closing and reopening the scan three or four or five times. Isn't failing to show scan data a really bad problem? Ironically, this is a problem we had with the original Centricity 2.x install twelve years ago at the same site. What a comfort it is to know that some things never change.

On the Agfa side, things are slowly improving. VERY, VERY slowly. Today, I was able to work at a barely-adequate speed from our remote site. Until the client started crashing repeatedly. In the middle of reading a scan. Fortunately, the digital voice (NOT SR!!!) program stayed up, making it a little easier to retrieve the lost exam. But this isn't the way things are supposed to work. I'm told that there were many "maintenance problems" that needed addressing. Why they weren't addressed before the radiologists had a collective meltdown I can't say.

So, we carry on. Dealing with all this PACS grief will inspire all involved to do better, to view not only gently, but wisely, and make judicious choices in hardware, software, maintenance agreements, etc.

Sorry. Just Kidding. We continue with business as usual.

Perhaps This Is The Problem?

“A Japanese company and a North American company decided to have a canoe race on the St. Lawrence River. Both teams practiced long and hard to reach their peak performance before the race.

On the big day, the Japanese won by a mile. The North Americans, very discouraged and depressed, decided to investigate the reason for the crushing defeat.

A management team made up of senior management was formed to investigate and recommend appropriate action. Their conclusion was the Japanese had 8 people rowing and 1 person steering, while the North American team had 8 people steering and 1 person rowing. So, North American management hired a consulting company and paid them a large amount of money for a second opinion.

They advised that too many people were steering the boat, while not enough people were rowing.

To prevent another loss to the Japanese, the rowing team’s management structure was totally reorganized to 4 steering supervisors, 3 area steering superintendents and 1 assistant superintendent steering manager. They also implemented a new performance system that would give the 1 person rowing the boat greater incentive to work harder.

It was called the”Rowing Team Quality First Program“, with meetings, dinners and free pens for the rower. There was discussion of getting new paddles, canoes and other equipment, extra vacation days for practices, and bonuses.

The next year the Japanese won by two miles. Humiliated, the North American management laid off the rower for poor performance, halted development of a new canoe, sold the paddles, and canceled all capital investments in new equipment. The money saved was distributed to the Senior Executives as bonuses and the next year’s racing team was outsourced to India.”

...from various sources around the internet

No Rush....

Time For Hope And Change

From one of my former partners, now bosses, who is taking back the night this week:

The situation with PACS is completely unacceptable. As you can see it is 5:55 AM and the system has been "down for three hours. My phone will not stop ringing with upset doctors that they have non reads and can't get images. ER can't hear my voice clips. I am rendering interpretations on monitors in the modalities on studies such as deer vs moped and attempted murder buckshot to the face cases. The problem is more than just my obvious legal exposure, but there is a notion somehow this is the radiologist fault, like we exert some control over this.

There was an ugly incident a couple of days ago with me and a PACS administrator in the reading room when I was told the problem was fixed and I had an issue. The next confrontation I fear will result in me saying something I will truly regret and this is my last warning email. Its time to go up the ladder and make changes.

And from the guy on the early evening shift:

PACS started the inexorable slow decline at about 9pm last night, with the usual >30 sec between studies, lack of initial response to mouse input resulting in cursor catastrophe when the machine finally caught up, and...a new one for me...the mouse cursor got stuck at the bottom of far right screen number 5...it took me forever just to find the cursor.

Is it unreasonable to institute a "no further imaging" point where, at our discretion, all imaging is halted until PACS resumes normal function? Otherwise, as stated above, we are liable for studies we cannot interpret per ACR guidelines, as the images are locked in a radiology purgatory. Continuing to scan patients and send them to this purgatory does absolutely no one any good at all. It only leads to the clinician unrest and anger our partner fought for us all last night/this morning.

This sounds eerily familiar...

Remember the Blunder Down Under?

To this day, five years later, my friends in Perth and elsewhere in Western Australia tell me their Agfa system still doesn't work properly. Now you see why Agfa has been very hesitant to share information with me!

It is quite possible this cannot be fixed. Agfa's PACS architecture is extremely complex, to the point that their own experts may not know what's going wrong with the system. Add to that a very clear reluctance on the part of our IT department to consider a network problem even in the face of clear evidence.

We are now backed in a corner. We cannot allow this to degenerate into another Western Australia debacle. For what it's worth, here are my suggestions:

First, someone needs to take a laptop to the data center and plug it straight into the server. If the PACS client works properly, we will know something about how the network is or isn't affecting performance. (Which we already know since different sites have different speed issues, and we get the best performance when connecting over the internet, but there are those who need proof...)

Secondly, given the crashes, it is clear that the problems go beyond the network, although I still think the network plays a significant part. Even if it isn't included in the contract (which I would like to peruse), the vendor needs to perform the next major update AT NO CHARGE given the current impairment to patient care we are experiencing.

Third, it is time to strongly consider moving to another vendor, this time using a Vendor Neutral Archive (VNA) which allows for easier migration in the future. I don't know the exact figures of how many exams and how much data we have stored over 20 years of PACS experience, but it would be a VERY major undertaking. Still, the switch to a VNA is something I strongly recommend even if we stay with Agfa. Keep in mind, migration from the old database could literally take years.

I haven't had hands-on experience with all of the vendors out there, but of course that doesn't stop me from having an opinion. While not everyone likes Merge/AMICAS, and they have had their problems at the hospital using it (although our group's system has had very, very few over the years), it has a much simpler architecture, built around a regular old web-server (Windows Server if you're interested), and as such it can handle a tremendous amount of traffic. I personally like the client (which I had a small hand in designing). The newer versions use a VNA database.

McKesson gets good reviews from the rads that use it, and in fact one of my bosses/former partners has had a very positive experience with it. McKesson was excluded from the 2003 PACS upgrade search because at the time, IT was phasing out other McKesson products for reasons known only to IT and would not consider any new McKesson product. Sectra out of Sweden has its fans and a fairly large US presence. Intelerad has a product similar to Merge/AMICAS that is certainly worth considering.

TeraRecon and a smaller advanced visualization company called Visage have something they call "deconstructed PACS" which overlays the existing database and provides another client interface. You still need your own VNA and other supporting components.

My short list ends there.

Based on our experience with GE's Universal Disappointment, and some insider knowledge, I would not even bother with them. Fuji continues to have many weird client problems, and locked-down software for which changes take years. Philips rebrands the web-based system once called Stentor. It is the last of the major programs that can't burn a DICOM CD readable by another PACS. People either love it or hate it. Siemens' latest PACS offering, syngoPlaza, hasn't taken off to any significant degree. There are a dozen more small PACS offerings out there that I would never recommend at all, let alone for an enterprise the size of ours.

For the very short term, IF our system cannot be brought under control, it will be necessary to do some form of overlay. From limited exposure at the last RSNA, the deconstructed PACS concept would work, BUT there are missing pieces such as the inability to generate a worklist, which requires another product. Years ago, an older version of AMICAS was used at Mass General as an overlay for their older (version 4.x) IMPAX to provide web-based access. With the proper interface engines, I think Merge could create an overlay to our database with full functionality. I think so, anyway.

It is validating, though sad, to have Dalai's First Law proven correct again and again:

PACS IS the radiology department.

Nothin' New

I wish I had something new to report on our current PACS issues. Sadly, I do not.

The Team of Experts from the Vendor, including the fellow who probably knows the software best of anyone in the entire world and beyond has been working feverishly. Things have been tweaked, caches have been cleaned, cookies have been baked, red heifers have been sacrificed, and the moon has been howled at.

Nothin' new. Bupkis. We don't seem to be getting anywhere. What hasn't been done to my knowledge is taking a workstation (or laptop) straight to the data center and plugging in right into the server. That might provide a hint as to what part the network and hardware might play in this little fiasco. Of course, the fact that the darn thing works near-perfectly (relatively speaking) when accessed from a regular old home broadband connection might be another clue. Yes, Colonel Mustard did it with a candlestick in the parlor. But hey, a clue is a clue!

When there's some news, I'll let you all know. But don't hold your collective breath.

Pointing Fingers At Meetings

PACS is complicated. Really complicated. Really, REALLY complicated.

So when something goes wrong, there is a lot of investigation that needs to be done, and occasionally, there will be a lot of 'splainin' to do. And here and there, people point fingers at the perceived source of the trouble. Sometimes they are right, sometimes they aren't.

As you might guess, one of our systems is having a problem, and we aren't getting to the bottom of it. And there is some finger pointing. As we are in the midst of working it through, but we do not yet know what's wrong, I won't name the name of any entity, person, nation, President, planet, or vendor involved. You may feel free to guess, but I'm not telling. Wild horses couldn't drag the information out of me. And I hate horses. Well, I hate riding horses, which is close enough.

So. Just the facts, Ma'am.

The PACS in question has never operated quite perfectly. You might say that none of them do, and I would have to agree. But this one has had a few operational issues, including occasional complete outages, which fortunately are few and far between. And you might say all of them do that, and I would have to agree.

But the system in question has always had some little glitches I don't see from our other sites. In particular, we have noticed over the years that scrolling of large data-sets can be painfully slow. Surprisingly, turning off annotations will speed things up considerably. No one has been able to explain this adequately, although some have suggested that it is due to this particular architecture having to communicate back to the mother ship server for every command and mouse stroke and click. Could be. Also, SOME of us, and not all of us, experience very slow searches, worklist refreshes, and so on. This bad behavior has been attributed to bad individual user profiles, and rebuilding them may or may not cure the problem. And it has also been said that because some of us keep multiple worklists active, and all of those worklists have to have a little chat with the server upon each refresh, we are the ones slowing down our own workstations. Blame the victim. Love it. But it might still be true.

We've been putting along like this for several years. I've complained, others have complained, things are looked into, things are tweaked, and sometimes we see some improvement. I do have to say the system has been usable, even with the glitches, except on those occasions when it dies completely, and then it isn't very usable at all. In the meantime, I'm informed that we are about the last site in this quadrant of the galaxy on our particular version of the product. Fits like an old shoe, I guess. We need an update, although no one is certain that will solve any of our problems.

Unfortunately, over the past month or so we have been seeing a definite deterioration in function. Things load slightly more slowly, then a bit slower still, and in some areas, including an ED and a remote site on the network, the speed drop has reached the point that the stations are inoperable. But here's a little clue for you electronic Sherlocks out there: Stations accessing PACS via the Internet, outside the Enterprise, demonstrate adequate speed. We get better service from a home station on a 50M Time-Warner home connection that the gigabit Ethernet inside the hospital. Hmmmmm. Aside from the network connection, the only other difference between a station within the network and outside is that our main reading stations have digital voice (NOT speech-recognition) software integrated, although the ED stations do NOT.

To me, this all points to a network problem, possibly/probably compounded by the way this particular PACS architecture works with the network topology.

Now here's where we get into trouble. It seems that IT and the vendor have been working on the problem for a month or more. And they have come up with nothing. Well, I've been talking with folks on all sides of this, and that's not quite true.

The vendor has run tests from sample workstations at multiple sites, and lo and behold, the site with the most trouble has significantly slower transmission speeds back to the gateway than the site with less trouble. I'm leaving out a lot of detail, but that's the gist of it. Sounds like the answer, yes? No. IT has run tests on the network, and the report is that everything is perfect, nothing wrong, nothing to see here, move along. And so the finger points to the vendor.

The vendor, for its part, is bringing in everyone who knows anything about how the thing works, and promises to do everything possible to get to the bottom of the bottoming out.

And that, dear readers, is where we sit today. All sides are supposedly working furiously on the problem. I think (I hope) they all realize the mission-criticality of what it is they are fixing. Remember Dalai's First Law:  PACS IS the Radiology Department. Right now, our beloved department is impaired. I personally don't care whether this is the fault of the software vendor, the hardware vendor, IT, or if the janitor slopped a wet mop on a server. Our system is absolutely vital for patient care, and we cannot begin to tolerate anything less than 100% function. And we cannot tolerate anything less than 100% cooperation to get us back to 100% function.

I have had the good fortune of creating an international speaking career based on some of the foolishness I've seen over the years on every side of the PACS equation, and that includes ridiculous behavior on the part of vendors, IT types, and yes, even radiologists. As a crotchety, cantankerous, semi-retired curmudgeon, I can say with confidence that with most PACS problems, all parties have some degree of guilt. It is really bad when one side digs in its heels and declares: "it's not my problem!" But there is something even worse: MEETINGS!  Many folks out there, often but not exclusively IT types who have come up through the IT bureaucracy and not via Radiology, know of one and only one way to handle a situation: We need to have a MEETING! Thus time and resources are wasted trying to get the Important People in the same room at the same time so they can all explain why something isn't their fault, and agree on the time of the next meeting. Yes, I know that's how things are done, but in my experience, it's more how things don't get done. My very favorite example comes from my early days of dabbling in PACS, now over 20 years ago. I was sitting beside the one and only PACS administrator, a good friend of mine, while an IT person was droning on and on about how thus and so wouldn't work, how it couldn't possibly work, and how they should all meet again in a month to discuss why it was a bad idea. My friend whispered in my ear, "I did it and it works just fine!"

No doubt I've stepped on a few toes with this little rant. I mean no disrespect, and I dearly value the friendships I have made throughout the years among IT folks and vendors alike. But I have very little tolerance for things that get in the way of patient care. A failing PACS is right up there. Let's not add squabbling and finger-pointing to my sh*t list.

Besides, if I should disappear tomorrow, you all might have to deal with some of my former partners (now my bosses) instead, such as the fellow for whom Dalai's Twelfth Law was written:

At least I speak the IT language. Which might not be all that appreciated in the end.

Dalai's note:  What happens in Vegas stays on the Internet it seems. I wrote about Bill Clinton's speech at RSNA, 2010 back in (surprise) 2010, and it was discovered only recently by Fox News. The anonymous donor who paid for Bill's rambling wreck remains anonymous, and in fact, there seems to be no record of the donation at all. Hmmmmmm....

Medical Bill: Mystery donor picked up $150G tab for 2010 Clinton speech

By Malia Zimmerman

Published July 10, 2015

| FoxNews.com

It was a big coup when a nonprofit medical trade group landed Bill Clinton as a speaker at its 2010 annual conference in Chicago -- so big that some members wondered how the former president was being paid.

Not to worry, members of the Radiological Society of North America were told: An anonymous donor footed his bill.

The $150,000 fee was a mere fraction of the $48 million Clinton took in from 215 speeches between 2009 and 2013, while his wife was secretary of state. Who paid Clinton and why they thought it was a fair bargain may never be known — but government watchdogs say it is a prime example of how elusive accounting can be for the ex-president's eye-popping earnings.

It was clear, however, that the husband of America's top diplomat was not chosen for his medical expertise.

“I think this is interesting that you would ask me to come and speak today to a group of people from all over the world, and everyone of you knows more about the subject than I do,” Clinton said at the beginning of his 45-minute address to an audience of 4,250.

Dr. Sam Friedman, a radiologist from Columbia, SC., said at first he was “peeved” when he heard Clinton was paid $150,000 for the “rambling” speech, during which Clinton took several “gratuitous shots” at Republicans and blamed U.S. doctors for many of the healthcare problems in third world countries. When he and like-minded members made their objections known to the organization, they were told the fee was paid by an “anonymous” donor. 

Radiological Society of North America spokesman Marijo Millette told FoxNews.com the group “strives to provide compelling speakers that will satisfy the educational needs and special interests of a diverse audience.”

Millette would not comment on Friedman's claim, which was also reported by trade media, but said Clinton's fee and travel expenses were paid to the Harry Walker Agency, which represents Clinton. The organization’s 990 forms, filed with the Internal Revenue Service and required to maintain its 501(c)3 status, do not list any payment to Clinton or his representative. Neither the executive director nor three executive board members contacted by FoxNews.com would divulge who paid Clinton's fee.

Matthew Whitaker, executive director of the Foundation for Accountability & Civic Trust, a Washington-based, non-partisan campaign and ethics watchdog group, said the anonymous donation “opens up a Pandora’s box of questions including who funded this speech and what their motivations were.”

“This issue has to be resolved," Whitaker told FoxNews.com. "There has to be an answer as to who gave the money. “It has the smell of someone trying to move money through an organization to curry favor with the former president. It also calls into question almost every speech Bill Clinton has made and who the ultimate funder is.”

Neither Clinton's representatives at Harry Walker nor at the Clinton Foundation responded to a request for the name of the mystery sponsor. It was not clear if other speeches by Clinton were similarly funded by anonymous third parties.

Tom Fitton, president of Judicial Watch, a Washington D.C.-based government watchdog foundation, said much of the $48 million Bill Clinton made from 215 speeches during the time Hillary Clinton was Secretary of State went to the Clintons' personal coffers, not to the foundation. Federal disclosure forms filed by Hillary Clinton for 2010 record her husband’s compensation as $150,000 from the Oak Brook, Ill.-based group, but critics say the lack of transparency about where the money really came from raises serious questions.  

“Bill and Hillary Clinton are married, so under the law, paying him for a speech is like giving money directly to her – to the Secretary of State,” Fitton said. “I cannot think of a comparable ‘pay to play’ scandal.”

Clinton gave 542 speeches around the world between 2001 and 2013, earning $104.9 million, and delivered another 53 speeches between January 2014 and May 2015, earning an additional $13.5 million, according to reports by Fox News and the Washington Post. The former president's speaking fees have ranged from $28,100 for a 2001 talk at the London School of Economics to $750,000 for a 2011 appearance at an event for Swedish communications company Ericsson.

While Clinton's knowledge of world events and charm as a raconteur is well-documented, critics doubt the sky-high fees are doled out by anonymous parties for sheer entertainment value.

"These donors don't cut checks because they want to hear a brief speech," said Sean Davis, co- founder of The Federalist, a conservative online magazine. "They do it to gain access or favors from the Clintons. The Clintons owe voters a clear explanation of who is funneling them this money and why.”

Belgian Rhapsody

Dalai's Note...Since IMPAX has decided to quit working this afternoon, I'm left with time on my hands, and we all know what the Devil does with idle hands...So please enjoy this repost from 2009, with a few minor enhancements . I wish I could say 2009 was the last time we had a PACS outage, but my creativity can only be stretched so far.... 

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 I.T…..

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

Too late, my PACS won’t scroll
Couldn’t label any spine
Lovely software past its prime
Goodbye to my worklist, it won’t update now
Gotta reboot yet again and hope it works
Mama, Ooo Ooo Ooo Ooo,
I can’t have it die
I wish sometimes I wasn’t a rad at all

I see a little problem getting back online
Waterloo, Waterloo, Can you make the damn PACS work?
Shorting out and sparking, keeping me remarking: OY!
Mike Cannavo, Mike Cannavo
Mike Cannavo, Mike Cannavo
Mike Cannavo make it work, oh make it work Ooo, Oooo,Ooo
But I’m just a poor rad and my PACS hates me-
He’s just a poor rad from a bad residency
Spare him the joy from this monstrosity
Easy on easy off, will you let me work
Just fix it! No we will not make it work-Make it work!
Just fix it! We will not let you work-let it work!
Just fix it! We will not let you work-let me work!
Will not let you work-let me work
Will not let you work-let me work
No,no,no,no,no,no,no,no
Mama mia, mama mia, mama mia let it work
The Psycho ward has a nice cell set aside for me, for me, for ME!
So you think you can patch me and tell me I’m fine
So you think that an upgrade will keep me online
Oh, baby, can’t do this to me baby
Just gotta hang on, just gotta stay online right here
Nothing ever matters
Anyone can see
Nothing ever matters-nothing really matters for I.T....
Any way the circuits blow….