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.