Top 10…or 19 PACS Problems

PACSman: I love how I’m given a list of the "Top 10 PACS Issues" to comment on, and it’s 19 items long. Mars and Venus says it all, if it wasn’t a list drawn up by a guy. Although, maybe Ms. PACS translated it into 19, adding her own stuff that isn’t in bold, which makes more sense. Who knows.

Here are the Top 10 PACS Issues, according to Richard (Skip) L. Kennedy, MSc, CIIP; Kaiser Permanente Medical Group, Sacramento, that will be discussed at the SIIM 2010 educational session on Thursday, June 3, 2010 in the "Practical Imaging Informatics Learning Track.”

 Top Ten PACS Problems

1. “It doesn’t go through…” Part 1: Network layer issues
2. “It doesn’t go through…” Part 2: DICOM layer issues
3. “It doesn’t do what I want/need/expect…”:
4. -Managing user expectations and user education
5. -Vendor feature requests and customizations
6. “It’s really slow…”:
7. -Performance management
8. -Scaling issues
9. “That can’t be right…”: Data QA management
10. “Everybody wants on board now…”: Imaging content outside of Radiology (Cardiology, Dermatology, etc.)
11. “You didn’t tell us about…”: User community communications and change management
12. “We need to get a new…”:
13. -PACS-to-PACS migration issues
14. -PACS hardware refresh issues
15. “We need to know…”: Dashboards and reporting issues with PACS
16. “What to do when the lights are out…”:
17. -Availability and uptime
18. -Downtime processes and procedures
19. -Disaster recovery

About 3/4 of the items on the list are technical issues. For the most part, those are a piece of cake to deal with. While they may not be solvable right away, they are solvable nonetheless. The other issues aren’t so easy.

My #1 is managing user expectations and user education. Will PACS solve every problem you have and meet every need? No. Will there be no downtime? No. Will it…the list goes on and on, and the answer typically remains the same - No. It’s even worse when you are replacing a PACS, expecting the new one to do things the old one didn’t do while you use the same RFP and get the same answers from the same vendors and expect the outcome to be different. Isn’t that the classical definition of insanity?

My #2 would be creating a vendor neutral system or at least incorporating a vendor neutral archive (VNA).  Despite 20 years of standards development, the vast majority of systems out there can still be considered proprietary or closed systems, each having at least one component from the database structure to the archive that locks in the end user. That is just plain sad. Vendors say they support a standard - all images are in a DICOM Part X format, for example, then they throw on a proprietary compression algorithm that only they provide. So much for an open system .

My #3 would be making sure the system is designed right. That didn’t even make the list. When you buy a PACS you buy what the vendor says is the solution based on your needs. The question remains: did you adequately outline ALL of your needs and did their solution meet it? This is easily addressed contractually, but few people include the proper contract language to address this.

My #4 would be…..well, you get the gist of it…problems are just masked opportunities for improvement. If you address #1, everything else is a piece of cake, but it’s like marriage - you never know what you are in for until you are in it so…Maybe that’s my #4. Once you make a decision to implement a PACS vendor, accept what you have and make the best of it. You are going to have it for a while, and getting out of it isn’t easy or cheap either. The upside of a PACS is that you get to choose a new one every 5-7 years without penalty.  If life were only that simple