When evaluating and selecting any new product to purchase, I am certain that almost everyone would agree that it is important to completely understand what the product can do. However, it is equally important to understand what the product cannot do. When it is a PACS being purchased, it is absolutely critical to understand both sides of the coin.

In speaking with prospects and clients, we at The Thomas Group Ltd (Anaheim, Calif) are careful to set expectations for a PACS project. In this edition of “Informatics Report,” I hope to do the same by clearly explaining some of the pitfalls of PACS that have nothing to do with what a fully functional PACS is designed to do.

Let’s start with what a PACS is:

Picture?captures the image. Instead of being printed on film, the captured images are sent directly from the diagnostic imaging modality to your PACS.

Archive?stores the image. Images are now permanently stored in an electronic archive.

Communication?distributes the image. This aspect includes how the images are viewed throughout the hospital on both diagnostic and clinical workstations as well as how the images are made available to the referring community.

System?manages the integration and interface to other clinical systems. Two of the most important systems to connect to are the RIS/HIS and the dictation system.

Of course, PACS is more complex than just this definition. Truly providing automation of your film/image-management processes requires the implementation of a fully functional PACS that meets your unique needs. We have worked with clients?who have purchased a PACS prior to our involvement?to evaluate why they were unable to obtain a base set of objectives. Ineffective system design is often the culprit. Being the architects of the system design and then being present at the go-live date, we’re very aware of what the trade-offs or impairments of inadequate design can be. Typically, these are flaws in a PACS design that can be tied directly to workflow intricacies that should have been addressed by PACS, but were not, in the original purchase.

Now that we know what a PACS is, let’s reflect on what PACS is not. You’re probably asking, “Why is that important?” As I mentioned before, understanding what a product can’t do is as critical as understanding what a product can do.

For starters, it seems that once the PACS project is on track, the system has been purchased, and the preparations are under way for the go-live date, many stakeholders will try to use the new system to do things that it was not designed to handle or selected to perform. When this is happening, you’ll hear such comments as: “Maybe we can fix this.” Or, “Maybe we can fix that.” Or, “Is there a way that PACS can … ?” Be forewarned: These questions are typically an attempt to have your new PACS do something that it was not designed to do.

Then, there are the people problems that PACS will not cure. For example, a PACS will not miraculously change a person’s work habits and make him or her suddenly start doing his or her job correctly. If a radiologist does not want to read certain images or modalities, or if he or she only wants to read certain exams, a PACS will not fix that. If a technologist has poor quality-assurance performance with film, a PACS in itself will not solve the problem. Lack of consistency in communicating images or image-informational reports to other clinical departments, or other issues of dysfunctionality, will not be fixed simply by implementing a PACS.

In summary, when you try to do something that PACS is not designed to perform, you are setting yourself and your project up for failure. Do not let other people try to convince you to set up a PACS to do what it was not designed to do. As I have mentioned in previous editions of “Informatics Report,” many things contribute to the success or failure of a PACS project. Typically, you will want to do as much as possible to support your success and minimize the actions that will, or could, limit your success.

On the other hand, maybe the technology will encourage users to do things that they previously were not willing to do. The key here is to implement post-PACS workflows that are enforced. Each person involved with a new PACS needs to be held responsible and accountable for his or her part in the process. The technology, in and of itself, is not the cure. However, it can be used as the catalyst for improvements and change. In fact, a PACS will deliver other efficiencies that could potentially enable someone to have even more time to do as much (or, gulp, as little) as they want.

Trying to put a square peg in a round hole will not be successful. Attempting to be all things to all people can set you up for limitations when the promised efficiencies are compromised for trying to put Band-Aids on other problems. Focus on what the product can actually deliver, show tangible and strong results early, and leverage that performance to drive your project. Get points on the board early, execute your game plan, and make room on the bandwagon. Everyone loves a winner.

Do you have a question for Michael Mack that you’d like to see answered here in “Informatics Report”? Email your questions to .

Michael Mack is VP of business development at the Thomas Group Ltd (Anaheim, Calif). Having more than 20 years of experience in the medical imaging industry, Mack now specializes in PACS planning and implementation.