PARCA eNews spoke to Mr. Cannavo by phone to get his perspective on the status of PACS systems and PACS administrators as medical imaging has evolved and moves into Enterprise Imaging.
His healthcare consulting services for end users include PACS optimization services, system upgrade and proposal reviews, contract reviews, and other areas. The PACSman is also working with imaging and IT vendors developing market-focused messaging as well as sales training programs. He can be reached at pacsman@ix.netcom.com or by phone at 407-359-0191.
Q. I have been following the PACS Evolution for years and I've seen everything from PACS is dead to VNA is the future and deconstructed PACS. So I thought it was time for a status check of where PACS systems are and where they are going, and thought the best person to talk to would be the PACSman. Where are PACS systems now and where are we going with them?
A. Goodness gracious where are they? Right are they deconstructed? No they're not. Deconstructed PACS is just another word for putting the pieces together that you want to make it work. Yeah, you know, I mean it's a little bit more complex than that, but not a lot.
Right now most people are buying replacement systems and about the only thing that is going on right now is complete replacement systems. And what most folks are buying are enterprise imaging solutions. You know, these are the same as a PACS but instead of having a dedicated archive for a vendor specific, dedicated archive, it has a VNA and often times includes a RIS or at least some RIS functionality.
Other than that, it's a PACS, but you know, you can get more money for it if you call it and EIS (enterprise imaging system) so it's all marketing.
Q. Are you saying PACS have pretty much become just a component of Enterprise Imaging Systems or is it that PACS are dedicated systems from one vendor and Enterprise Imaging Systems can have components from multiple vendors.
A. The difference is most PACS are turnkey systems from one solution and Enterprise Imaging Systems can be from one vendor but typically includes a vendor neutral archive where they can also input, you know PACS is radiology-centric or focused on a full radiology system or full cardiology system whereas an enterprise imaging system typically has a VNA that can accept images from radiology from cardiology from pathology or you know, anybody anywhere. There else not much of a difference beyond that.
Q. As organizations move to these enterprise systems, one of the big hurdles Herman (Oosterwijk) talked about in an Aunt Minnie interview, is accommodating all the different workflows from different service lines. PACS is really good at handling scheduled workflows, whereas many of the different service lines are more encounter-based what are the strategies being used to integrate those kinds of work flows into the Enterprise Imaging system?
A. There are definitely different workflows between radiology and cardiology and some of the other ologies. Cardiology, for example, does a boatload of color and full motion whereas radiology does very little color. Some might do colorful Doppler and subject medicine stuff but very little full motion. There's a bunch of differences between them. One of the biggest things that you're going to find is that the use of artificial intelligence is going to really have an impact in terms of storage because AI is just another report that they're going to have to archive and store. Can you restate your question if you wouldn't mind?
Q. Well what are the challenges in integrating all these different workflows into an enterprise imaging system.
A. Integrating the different workflows, you're not going to. They're going to stand alone. The applications are going to stand alone. It is just using the hardware whether the archive is done on-site, on-premise or whether it's done in the cloud. Okay, that's the basic differences between them. You are not going to have a single workflow for all the ologies right, radiology will have a completely different workflow than cardiology and that's just the way it is.
Q. Interoperability has also been one of the challenges. Are we making progress there? Are we there yet?
A. Well slowly. I mean you've got standards out there like FHIR and you've got smart FHIR. You have a whole host of different interoperability standards. The issue is from the time the standards are first announced and released until the time that the standards are actually adopted can be four or five years, because the vendors have to examine them. They have to test them. They have to validate. The vendors have a lot to do before they finally adopt the standard and by then there's a new standard that comes out. So, you know, I mean again, that's the nature of the beast.
And as I’ve said, it pretty much comes down to all customized APIs, which is an application program interface. It's a custom interface. So, are they are using this standard, and are they using that standard and no, basically they're one-off custom interfaces at this stage of the game because there aren't that many people playing in the in the AI world.
Yeah, the only folks that are really playing AI world are academic facilities and a few luminary facilities and the academics are, I don't want to digress from PACS, but the academics are getting their funding from the NIH they have nothing to lose nothing to worry about, and a luminary facilities are getting hellish deals if not free to go with them, but it's all they have to do is pay for the interface or have somebody take care of the interface and they're golden.
I mean the name of the game for any of the stuff is how do you pay for it? How is it going to improve radiology workflow? How's it going to improve cardiology workflows?
If there's one takeaway quote that you can put in this this article it’s “workflow is everything, the hardware is simply hardware, software is simply software. It's how you use the hardware and software together to go ahead and improve the radiologist’s productivity and the technologist’s, and in improving their productivity means that you improve the workflow how they do their jobs if they can do it faster better and ultimately cheaper.”
Q. From what I have read about improving that workflow, one of the things that's coming up as a challenge with enterprise imaging is that traffic across the network is very uneven because different service lines need different access to imaging and so there's a problem there and I think you talked about load balancing. Can you talk a little bit about that? What is the challenge there and how are PACS administrators addressing load balancing?
A. Load balancing is one way that you deal with traffic flow, especially if there is a high volume demand like a thousand slice CT study that's coming across at one time. But frankly with traffic if anything the biggest issue isn’t traffic It's latency. Latency being the time it takes to get from one site to another. I don't want to give you a definition because I may be incorrect but basically latency is delays in images getting from one place to another.
Right now, I mean a lot of networks are gigabit networks and they are more than broad enough to do just about anything, you know, the issue that you get into is when you're trying to throw a huge mammography study for example, field digital mammography study or a stereotactic mammo at the same time that you're throwing a huge cardio across the same pipe to the same destination most of the times.
PACS have VPNs or virtual private networks where they have a segment of the network that is their own and nobody else competes for so that's typically what happens is you have radiology on a VPN, cardiology has a VPN the two bigger users right on their own lane on the same network, but on different segments of the network, I think that you can have load balancing that distributes traffic accordingly and if there's issues load balancing has become dirt cheap, well they're cheap relative to the cost of other things in enterprise imaging. When I say cheap, you're looking, you know, $20,000 or $25,000 and sometimes less, which is like you and I going out to buy lunch.
Q. What other challenges are PACS administrators facing?
Causing heartburn for PACS administrators right now, the biggest issue still is that when you're changing PACS, you still have got to do with data migration. It still is not fast. It can take a year or more to do the data migration. You may not get all of the studies. You may not even get half of the studies that migrated across the first time so you may have to do it multiple times to make sure you get most if not all of the studies. It's also not cheap. A lot of people don't budget for data migration.
And data migration has to be done first because you've got to have your priors. The radiologist can read a current study without the priors. Right? So you you've got to get your priors and your currents together.
Q. That has been a problem with PACS from the very beginning. Has there been any improvement in the way data migration is handled?
A. Not really because it's not just the data that's migrating, it's the data and the database both. Data in theory can be a DICOM part 10 and should come straight across fairly seamlessly, but there are some vendors that still store data in a proprietary format and all vendors have their databases that only they have access to. And you can't transfer the images without the database so that puts you at either using the vendor to do the data migration or using less than a handful of third-party vendors who have shown that they can do data migration on behalf of the facility.
Laurel Bridge for example is one of them. I don't know if you name companies, but I mean you can have companies that can do the data migration, but then again if it's not the vendor doing it, you may lose some of the data that's in the private tags, how important that is remains to be seen. You know, for some people it is very important for some vendors. It's not.
So, you're at the vendor’s mercy because they own the database and databases are proprietary. Everybody has a little tweak in a little something that makes it proprietary and you have to go to vendor. No vendor allows an end user access to the database You can quote me on that part.
Q. Has that been the big problem with interoperability, an unwillingness of vendors to break down those barriers.
Let's just let's just say, I’ll use the analogy. It's a great analogy, but it's not politically, correct. If you're going to throw hypothetical names out there if you are Phillips and the customer is going to replace you with Spectra. Okay, they have a contract with Spectra and then come back to Phillips and say we need you to go ahead and transfer this data over to Spectra that's tantamount to you having your ex-wife cook dinner for your new wife.
And then you know when you finally get to the dinner, if you're smart, you will sit back and trade plates with her and watch her eyes. I mean that's kind of the way it is. If you’re going to replace one vendor with somebody else, they are essentially going to say, ‘you want me to cooperate with you. Are you out of your mind?’ Yeah, because the vendors don't make the money on the PACS.
I'm writing an article on that right now. It’s a misnomer, vendors don't make money on the PACS itself, they make the money from the service contracts and they want to maintain the service contracts at all cost. Everybody has a service contract and that's where the money is made.
Because the service contracts come as a percentage of the list and that's key. Say the list price of the system is $1.5 million dollars, but you actually end up paying $500,000. The service contract then is 15 percent that they can get per year based on the 1.5 million. As a result, the service contract is going to cost $225,000 per year on a system that you only paid $500,000 for to begin with.
That's where the money comes in, and in no way on God's Great Earth are you going to get $225,000 in service in a year. If you need $225,000 worth of service, you’re in deep trouble. That's where their money comes from their service contract and is typically a five to seven-year period of time.
Q. Is there's anything PACS administrators or network people can do to defend themselves or protect their organizations from getting caught in a situation where it's just impossible to get out of that situation?
A. Absolutely nothing. There are no vendors offering genuine performance guarantees, vendors offer acceptance criteria. But the performance guarantees have no penalties associated with them. We're going to guarantee that a 500 slice CT will display the first image within five seconds. Well, what if it doesn't?
You know, they may give you two percent off the service contract for that month if it does it consistently, but typically there's no penalty. Another guarantee they offer is you will get the service contract for free if the service level falls below 80 percent.
In reality, if your service level falls below 80 percent there's going to be a bunch of radiologists with AR 47s, they're coming at you with guns blazing. Yeah from a reality standpoint if your service level falls below 98 percent these guys are going to ballistic.
I've got a client now who is complaining about a system that's taking 10 seconds instead of five, and I'm like, okay, so there's an issue let’s give the vendor a chance to figure out if it's latency issue, or if it's a workstation memory issue, if it’s this issue or that issue. It’s not like the damn system is down, you know, the performance is the performance. Every system has hiccups, every system has problems. That's why you have a service contract you call.
You go to the vendor and you say I'm getting slow image display. I'm getting this the vendor looks it up find out what the problem is fixes it and you go on your merry way until three days later when you have another hiccup and then and that's the same situation. It's a political system.
The problem that we don’t often talk about is that PACS users have gotten spoiled. I got really irritated at one client who was who upset because something had taken seven seconds instead of five. I said, ‘Doc. Let's do this. I understand you are really not happy with the system. So let's pull it out and we'll put your film library back in and we'll let you go back to the old way.’ He looked at me and said are you out of your mind? I looked at him and I said, ‘Are you?’
We’ve gotten used to getting things instantaneously so that users become spoiled and that's the problem. If there's an industrywide problem it is we've given radiologist and cardiologists and others on these Enterprise Imaging Systems an almost unrealistic expectation of what they can expect. They expect images in three to five seconds and if it takes seven seconds or 10 seconds, they are screaming yelling and jumping up and down about the system. I just wrote an article, it'll be on Aunt Minnie in another day or two. It's called “Our PACS sucks and how we fixed it.” And the problem is that nobody manages the expectations of users.
Q. To kind of just wrap it up what with all the changes what do you think the future looks like for a PACS administrators? Are they just going to be absorbed into the IT department or how will it all work?
A. The reality is, it’s a lot easier to teach a radiology person IT stuff than to teach an IT person radiology stuff. So is there a future for PACS administrators? There will always be a future for PACS administrators but more and more, the role is getting involved in the day-to-day operation of PACS and what you have are things like data dashboards coming out that will notify the administrator if there's a an issue or problem and they can proactively take care of it. That's really the role that PACS administrators can have is to just proactively take care of problems before they become issues, to be able to monitor the system stay on top of it and then find the resources necessary to address the problem before it becomes one.
Dashboards are going to be crucial because they'll tell you if you hit a high-water mark at 70 percent or 75 percent you hit that high-water mark. Hey, there's a problem coming up take a look at it. They look at it and say okay, it's a network problem. Let me call the network folks at IT. It's a hardware problem. We call the hardware folks and it I mean PACS administrators will play that role and the role of being a proactive resource not waiting until they have to call the vendor and then the vendor has to dial in and look at that. They have to be proactive. There's always going to be a need for PACS administrators.
No comments:
Post a Comment