In a session near the close of the recent SIIM Conference in Aurora, Colorado, four imaging informatics managers shared tips on creating contracts for effective vendor relationships. The takeaway: a good contract should strengthen the relationship and head off any disputes.

The four experts on the panel for the session, entitled For Project Leaders: Preparing for Successful Contract Negotiations were:

Donald Dennison (moderator), president, Don K. Dennison Solutions Inc.
Stephen Besselman, project manager, El Camino Hospital
Robert Coleman, senior director imaging informatics, Maine Medical Center
Michael Toland, PACS team manager, University of Maryland Medical Center

The interactive session took on a question and answer format. Here are some of the highlights by general topics.

Before entering into contract actions, such as an RFP or demonstrations, what are some of the things that an IT manager can do be more prepared?

Besselman: We used an outside consultant who prepared an extensive pre-screening questionnaire. We referred back to those questions during the vendor screening to make sure they could do what they said they could do.

Toland: The more info and details we can share with vendors, the better. The first thing we provided is the organization’s standard purchase agreement, so they go could through and do their redlines (proposed changes). We post our service line agreement that vendors have to live by, and we can check to see which vendors read it.

Coleman: When you enter into a contract, it’s really starting a relationship. In some cases, you’re going to be living with a vendor for years — I have some vendors I’ve been with my whole career. We use a very vigorous technical review about ten pages long.

Dennison: Remember, your general counsel doesn’t need a PACS, you do, so come up with practical thresholds. A one-sided contract won’t work for anyone. Think about the performance measures you need that will help a vendor anticipate a problem. Three common contract metrics are 1 — service uptime (planned and unplanned); 2 — the speed of the system performance and how fast and how many images can be read; 3 — the vendor response and resolution times.

What is your approach to contract details, such as the service agreement, statement of work, and cybersecurity?

Coleman: How many of us in this room have gotten a phone call from a radiologist who says, "PACS is slow today.”? We all hate those calls. So, it’s important to define success and failure in the service agreement. What is slow and how slow is the system running? There need to be penalties for lack of performance. Remember, vendors are not going to want to put real teeth in a service agreement.
But on the other hand, you shouldn’t extract a huge penalty if the system is running a second slower than specified. If everything is defined, and well, in the statement of work as early as possible, you to know what you’re buying and the vendor knows because it’s written down. You don’t want to rush this part.

Besselman: First determine if a problem is their fault or our fault. Firewall, storage, load balancer — that’s our fault. A slow phone tree response is their problem. You have to be precise in how you’re testing. We did put penalties into our agreement, intended to keep them (the vendor) honest — such as (free or discounted) software upgrades. On security, we do that assessment before the vendor even comes on site. Vendors need to document a security penetration test with our head of security and share how they will keep us up to date on this.

Dennison: The big thing is how do you get access to your database if a contract is canceled. But it’s best to have small release points in a service contract to deal with specific issues rather than have to rely on a catastrophic cancellation. Also, a thousand-page agreement or contract does not make your life any easier at two in the morning (due to a system failure). Have a working, useful agreement.

Toland: A vendor should be able to anticipate problems. We conduct quarterly reviews to make sure the vendor is meeting performance metrics. The system should be able to tell you that. For example, I get a message on my cell phones if the PACS system is running slow.

There are a lot of smaller companies that have been in business for five years in the enterprise space. What are some tips for working with them?

Toland: Have language that covers what happens to the contract if the smaller company gets bought out to by a bigger company. We have language in our standard agreement that covers this scenario.

Besselman: Do a financial background check to make sure the company is viable.

Coleman: Part of our job is to help the vendor be successful. We work with a lot of smaller companies because big companies are not as likely to make exceptions for what we need. I enter these agreements with a win-win mentality because if I do well, they will do well. The statement of work should be discussed as soon as possible

Dennison: You can put source codes into escrow, so if the company disappears, you can get your information back. It's considered to be a bit archaic, but it can be done, and there are attorneys who specialize in these types of arrangements.