An HIT Moment with … Bill O’Toole

An HIT Moment with ... is a quick interview with someone we find interesting. William O’Toole is the founder of O’Toole Law Group of Duxbury, MA.

The following are my top three suggestions for negotiating HIT software licenses.

Say what you mean and mean what you say

Determine up front what is truly important to your organization. Establish your contract priority list prior to negotiations. Include as much input as possible from the CIO, CFO, CEO, consultant, and legal counsel. The more complete your list is up front, the better the vendor can establish what it must deal with to land this new customer.

Don’t label something a deal breaker if it is not. Many times I gained the upper hand after responding negatively to a supposed deal breaker issue, only to have the prospect roll on it. Do identify your priority list up front. It does not have to be detailed or extensive. Get the message across early and put it on the table for all to see. Refer to it as revisions are turned. If the vendor does not address an item, raise it immediately.

Identify who is driving the bus

On the customer side, it is usually the CIO or CFO. Establish early and keep this person informed and involved. Others may handle conference calls and meetings during negotiations, but having the person in authority identified helps immensely. Have the vendor identify the individual in charge of negotiations, even if that person is not involved in each conference call or meeting. If things get rough on a specific issue, it may be helpful to have the two “drivers” talk directly after being brought up to speed by their respective sides in order to cut out all the dancing and grandstanding and get right to the issue. Marching orders can then be given back to the negotiating teams.

Do not dictate the terms by which you expect the vendor to license you their software

Setting the stage in this manner only creates an adversarial process, which is not what you want. It sets you up to become just another sale where only the money counts. Approach it as a relationship in the making. Know what you want (see above) and present a priority list, but do not dictate terms or you will get far less cooperation and poor results and ultimately be left unhappy with the deal.

Vendors always talk about being partners with their customers. If you were representing the customer in crafting such an agreement, what terms would you consider essential to truly aligning the vendor’s interest with theirs?

This is a really good question. The term “partner” is way, way overused. Unfortunately that really dilutes its importance. The ultimate indicator of partnership is sharing, whether it be capital investment, development effort, or risk. HIT vendors all thank their customers for choosing them as their HIT partner. But are they really partners? If a vendor truly wants you as a partner and not just its next customer, then you should realize real benefit in at least four major areas.

Payment for performance

If establishing a true partnership, then there should be a willingness to include terms reflective of such a position. Progress payments should be tied to measurable or identifiable events. Further, there should be a willingness to delay or forego (in some specific amount) payments if the events are not met.

Exposure

Government regulations, public entity constraints, and potential liability are prime examples of areas in which a partnership can be created as opposed to a strict customer/vendor transaction relationship. How much is the vendor willing to do or risk for its customer? The more the vendor risks, the more of a partner your organization becomes.

Near term and long term costs

Nail down the cost of acquisition and implementation. The customer partner should have absolute comfort in the cost outlay for the project. Not to the dollar, obviously, but certainly a solid figure assuming no significant deviation in the project. Long term costs should be predictable and you should never pay twice for the same product.

Development

The vendor may find your business of such importance that they are willing to offer you the opportunity to be a beta site or to provide input on development of a key area of software functionality. These opportunities can have both good and “not so good” ramifications. Weigh the pros and cons carefully. While this is a very strong indicia of partnership, it can be a tremendous amount of work for the customer.

Some people think putting performance penalties in contracts starts off the vendor relationship on rocky footing, while others say the only way to get a vendor’s attention when problems arise is to hit them in the checkbook. Should software contracts include penalty terms?

With regard to the initial implementation process, there should be no need for penalties if payments are based on attaining measurable milestones during the implementation (see above). This puts a positive spin on the issue. Pay the vendor for work done as planned. You arrive at the same result, but in my scenario, money is due when work is done, rather than the negative approach where money is not due because work was not done. With regard to ongoing support, it gets a little tricky. If you applied my implementation scenario, full payment would be due only if there were no issues in the service period, not a realistic scenario for any vendor.

So it could be argued that penalties make sense in the ongoing support situation. That said, it only adds another layer of work for the customer and the vendor, which is not something a CIO wants. Ultimately the CIO and CFO will withhold payment if things go really bad, so work with that concept. Negotiate the ability to withhold (delay) support payments in good faith if good support is not provided. Put the work on the vendor. If the vendor’s accounts receivable personnel are looking for payment and the customer reports payments are being held due to support issues in accordance with the contract, then those receivables folks will go to the vendor’s support personnel, which will escalate issues on the vendor’s side with little input from the customer.

In short, I believe that with regard to ongoing support payments, the time spent on identifying penalty situations and associated dollar amounts to be credited is better invested in personnel involved in resolving the underlying problems or issues.

Porter Hospital is involved in lawsuits involving the transfer of software rights to an acquiring organization. How often do disputes over legal ownership and transfer rights occur in healthcare and how do vendors look for noncompliance?

Fortunately I did not experience many disputes in this area during the past two decades. I use the word “fortunately” because these situations are fairly straightforward and end up costing the hospital(s) money.

That said, my experiences all demonstrate that the licensees did not do their homework. Transfer restrictions are not complicated and all vendor agreements have some language clearly stating what is permitted and what is not. Most often these matters involved spinning off a single hospital from a multi-facility license, or the acquisition of a hospital operation from a bankruptcy proceeding. I do not want to come across as preaching from on high, but in any divestiture situation it is incumbent on the parties to do a thorough job researching the items to be transferred, and I did intend to use the term “parties”. If I were on the acquiring side, I would absolutely review all the pertinent documents to make sure everything was in order. Time spent up front is far cheaper an investment than time spent in resolving a later conflict.

As for how vendors look for non-compliance, in the case of my former employer, we found that these matters usually have a way of popping up without extensive watchdog action. For site licenses, it is fairly obvious when the customer calls for assistance setting up a new facility or troubleshooting software tied to a formerly unrecognized facility. In situations involving machine licenses, the trigger is often the request for technical support for unauthorized hardware or for an upgrade or addition of hardware. User licenses may be the ones that go unnoticed unless the vendor routinely performs audits.

In my opinion, the licensees in these situations are not (in nearly all cases) maliciously trying to beat the vendor out of a fee, rather they just are not familiar with the restrictions on their systems. Once again, I suggest that being vigilant up front is less costly for the customer.

What’s it like leaving a corporation to set out on your own?

Daunting, yet comfortable. During the past 20 years negotiating HIT agreements as MEDITECH’s Corporate Counsel, I interacted with thousands of healthcare executives, attorneys, and consultants and experienced an amazing array of perspectives from healthcare entities, ministries, and governmental agencies throughout the United States, Canada, and beyond.

As I considered the next 20 years of my life and career, I realized that there are very few individuals with more experience than me in this practice area. Coupling the confidence MEDITECH management had in my work and the authority they gave me with the compliments I received from healthcare executives at the conclusion of countless deals, I realized that the prospect of establishing my own law firm demanded strong consideration.

Although it was difficult to leave MEDITECH after so many years, I decided that I would be successful and would do well for myself and my family by offering my services to the healthcare industry. It was very telling for me that just prior to my departure from MEDITECH (once the word got out that I was leaving) I had several contacts from entities seeking to retain me once I established my practice. So although no reasonable person would be without some concern in my situation, I am carefully confident that I will succeed.