A recent survey found data storage to be one of the more pressing issues weighing on the CIO mind. And when one tries to pinpoint the culprit for most of that data, it’s inevitably imaging. Just think of your inboxes, how easy is it to just delete the photo attachments from messages and shrink your footprint in seconds. For CIOs, multiple PACS and image redundancy are sure ways to exponentially increase storage costs. Recently, HCI Editor-in-Chief Anthony Guerra chatted with Jim B-Reay, vice president, business development at Healthia Consulting (acquired last year by Ingenix), about how CIOs can work to get their imaging houses in order.
AG: Talk about the typical issues you're approached with; for example, is it CIOs that are coming to Healthia? What's a typical example of some problems they might need assistance with?
JB: What we’re seeing right now is that, to an extent, especially in the year 2008, PACS has grown. I would say that in 2002-2003, it was one of those strategic initiatives that CIOs were really putting a lot of their work into, much the same way the hospital CMOs and CEOs were getting involved in whether or not they should upgrade their modalities to digital, and there were a lot of those challenges. By this point, it’s almost a foregone conclusion that if you're going to be doing imaging, you’ve got to have a PACS. And so almost all of the major institutions have got some form going and almost all of the vendors have reached a level of parity.
Where we’re getting engaged is on two levels. The first one is we've been brought in on a number of situations where the hospital is looking to almost start over with a digital hospital solution. They want to know, okay, if we were going to start with a blank piece of paper, how should we be pulling this all together. The other area that we’re being brought in on is what I would call departmental expansions of PACS. What I mean by that is that now cardiology is asking for their own functionality, orthopedics is asking for functionality, obviously mammography has always been in the picture, but they're starting to have greater demands for access to the imagery. So what we’re being asked to do is start to say, ‘Okay, does our current PACS architecture support this; if not, what needs to be our solution?’
Unfortunately, what we’re seeing is that PACS on a radiology level is relatively mature, but on almost every other level, it’s still a bit Wild West, and there is still a lot of replication of data; there are still a lot of interoperability issues, and they're very specialized toolsets. And so, we’re in a position where if somebody is saying, ‘We’re an orthopedic specialty practice, I’ve got 15 terabytes of spine files out here; are you telling me that to work with this new PACS tool, I need to copy that data every time?’ Unfortunately, a lot of the times, the answer is yes on that. Everybody wants to be strategic, but there are a lot of cases where the vendors simply aren’t there yet. Going way back, the blank piece of paper gigs are always the most fun, partially because they remind me of the early days of PACS because you really did get to look at all the options. Right now, it is such a mature market.
AG: I would imagine few organizations can take the ‘blank slate’ approach because most need to leverage their existing investments, correct?
JB: Right. At least two of the organizations we’re working with right now are actually smaller community hospitals who are expanding and acquiring other smaller community hospitals. So they're looking for a solution that will work across their facilities. And in those particular cases, there is opportunity, I think, when it comes to the core PACS. There have been a lot of cases where a solution has been put in place and it works great for a single facility, but it doesn’t scale to a larger facility. And that is a case where we get to come in and make recommendations for more horsepower, better architecture.
The other thing that we've run into has been just in a few cases, it hasn’t really been a groundswell just yet, but we have been asked more than once to evaluate a mainstream PACS solution and find out whether or not a replacement is a good idea. This relates to some of the vendors, which the names are familiar, where either an acquisition is going relatively poorly, or they really haven't lived up to things. There is the major group that was acquired just in the last year, and we've fielded more than a few calls saying, ‘Should we get out of that PACS and start to move our data?”
There was another one I was working with on a purely cardiac level where the vendor had been acquired midway through the implementation and we actually looked at the contract and got out of it. So there are some strategic things along those lines as well that we've been working with.
AG: Are you seeing a lot of issues with hospital systems that have grown through acquisition, winding up with PACS from different vendors? How much do you see that versus CIOs struggling with an imaging strategy that has just gotten away from them?
JB: I would say it’s more of the former where you’ve got three different PACS going in an enterprise and, ‘We need to get down to one because we’re trying to streamline our radiology group solutions and they're complaining about having too many tools.’ That’s the bigger issue. Simply because the specialty focus areas are where you do get into a lot of replication of data and sci-fi toolsets, there isn't always that much overlap between the user bases. It’s the infrastructure group who starts to really wonder about why we need all these servers, why we need to have all this replicated data. Believe me, the cardiologists are just fine with having their own system. The orthopods are doing fine, and the radiologists are fine, because they're not crossing paths that often.
There is not as much frustration. For them, they can say well fine, I’m going to go to McKesson for my CV images, and I’m just fine staying over on Emageon for my radiology images. It makes sense to me/to them because an echo image in a CV series, I read it in a completely different fashion than I’m going to refer to this CT. They almost look at it the same way as going off for EKG.
However, we are starting to see something where a couple of the vendors are really starting to understand that, especially in a specialty area (cardiology being one of the bigger ones), there is huge benefit to trying to integrate these things. I just went through something where we were moving to one system to integrate from two different systems. So there was a CV PACS for the cath and there was an echo PACS for the echoes and of course, both docs need to look at each other’s data a lot. So we moved to one system for that. That coincidentally was the one where we were halfway through the migration and the acquisition was finished, the strategic direction of the tool started going in a different way. Now we’re in the process of doing a do-over to actually bring in a third vendor to move everything to and then we’re actually going to start moving EKGs into there. It was a multi-step and we actually, through contracts, it didn’t wind up hurting much, but the CIO has been very involved in this solution. And unfortunately, they never want to hear that we made the best decision we could based on the data we had. But as long as we were able to make it be a revenue-neutral solution, she was satisfied with that.
AG: What advice can you give to CIOs so they can evaluate if their imaging plans are going in the right direction?
JB: One thing that they need to do is they need to decouple their infrastructure situation from the use cases. A lot of times some of the financial pressures and some of the squawking will come from your infrastructure group who will say, ‘We've got replication/we've got duplication.’ To that end then, you need to actually engage the physicians and find out exactly why these different tools exist and what the specific functionality is, because where you will run into major issues is if you go on a spec sheet and say, ‘They need to do this, this tool has this … they need to do that, this tool has that.’ A lot of times, we’re not taking into account some of the workflow and some of the more specific ways in which they're using that imagery.
I’ll give you an example. I was working with a small pediatric orthopedic rehab hospital. They had made a selection of a toolset that had very specific orthopedic templating tools involved and integrated with it. The problem was they actually had a relatively weak non-orthopedic tool profile. The director of radiology started a process to go through and start to move this whole thing toward an entirely new solution and wound up missing two of the key very specific targeted features that the orthopedic group was counting on the software for and wound up needing to renew their contract and actually is now settled with two PACS solutions. That was a case where they wanted to standardize and bring things down, but they actually wound up with two toolsets, and we’re still working our way through that one. People were unhappy with its scaling, and yet the docs were unwilling to part with some key functions.
CIOs must really engage subject matter experts even more than departmental directors. It has to be a physician advisory group who helps you out with that. I’d say you might want to also think about bringing in an external consultant for a targeted engagement to do an assessment … I’m not trying to sell here … but what I’m saying is that there is true value in bringing in an external person who can talk then as a peer to the docs, to the radiology department, to the infrastructure team and to the CIO to make sure that everybody’s objectives are aligned. And if they have internal resources that can do that kind of work, that’s great. But I’ve just found that that’s where some of my value has been.
AG: Do you think that it’s the CIO’s role to make sure this gets done properly? Do they have to be the gatekeepers who say to cardiology, ‘No, you can't have that system you want because it’s redundant or it’s just not necessary’? How should that dialogue go?
