Home » News » Currently Reading:

HITlaw 7/18/11

July 18, 2011 News 2 Comments

Who’s On First?

Recent O’Toole Law Group engagements have raised a critical issue that’s worth passing on to HIStalk readership.

When providers contract with vendors, they expect certain products and services. This much is obvious. The issue presented here arises as a result of all the distributing, bundling, packaging and rebadging of products.

Vendor A may offer Vendor B’s product alongside its own products. In this case, Vendor A is a distributor (and usually a reseller) of Vendor B’s product. Typically this type of collaboration exists when the two products perform related tasks for the provider. Like ice and your favorite drink, each is good, but together they are great!

Vendor X may offer a product called “TurboEMR” that also has some type of label like, “powered by HISware” or something to that effect. This probably means Vendor X has HISware’s software embedded in its product, and the “powered by” refers to this fact. In this case, Vendor X is sublicensing technology developed by HISware.

In each situation, the provider gets the package deal and the functionality it is seeking, which would not be possible with only Vendor A or Vendor B in the first instance or with only Vendor X in the second.

So everyone wins, right? Hopefully, but maybe not.

When things go well and you have a great prime vendor that really steps up and fills that role, life is good. The provider gets precisely what they signed up for. They have a single point of contact for resolution of problems with any of the products involved.

But what happens when things go wrong? Are the responsibilities and procedures clearly set out? Key contract components that must be addressed fully by all vendors involved include support obligations, copyright / patent protection, indemnification, and liability provisions, to name a few.

How does the provider determine exactly what they are getting and precisely whom they are dealing with?

One simple way to determine the “who” part is to look for the warranty of ownership. Something like, “Vendor warrants that it owns the software.” Once you find that section, really analyze it. It is probably not more than a sentence or two, three tops.

If the vendor warrants that it is the developer and sole owner of the technology being licensed, then you are dealing with a single vendor and its products. This is the cleanest, most simple scenario.

(Quick sidebar here: it must be a warranty, not a representation. Warranties have certain protections and remedies that representations do not.)

If the vendor warrants that it is the owner of the technology OR that it has the right to license it, that is your red flag duct taped to a flashing light. This is not bad, but it means the product contains or is packaged with third-party software. You need to be aware of this and you must obtain certain crucial contract terms for your protection.

The best-case scenario (keeping in mind that there is another vendor involved that is not a party to your agreement, which is the reason behind this article) is a warranty from the vendor that you are contracting with that it has warranties of ownership, operation, and error correction (for example) from the other vendor. This is critical because it can then be used to back up the same warranties from your selected vendor to you.

The biggest warning flag you could ever encounter is where there is a disconnect in the protection(s) offered. If the vendor warrants that “all software is great and works fine and they will fix everything, but this warranty does not apply to a certain line item or product,” then you have a problem. What happens if there is a failure with the excluded software?

If you have no answer while reviewing contract language, just imagine the discomfort you will feel if your system is down and all indications point to the excluded product.

OK, stay with me here. All the legal stuff aside, what those in IT really want to know is what happens if there is a problem with the products.

As stated before, with a solid prime vendor you are in good shape. But what about those unfortunate situations where fingers get worn out from all the pointing?

To try and avoid heartburn later, fix the contract up front. Try this simple exercise. Remember connect the dots, those partially finished pictures in coloring books with numbered dots? Connect them in numerical order and complete the picture! Give it a try with your software agreement.

If you have more than one vendor involved, just imagine a system crash, and then try to connect the dots to all the vendors, especially the vendor behind the scenes. Do you have adequate warranty protection? Do procedures exist for escalating a software problem to the correct level at the vendor? Can you get to the vendor at all??

Make clear for each product included, or component thereof, which vendor is responsible for support, updates, fixes, etc.

Make certain that you have contract pathways to obtain that service. Assume vendor A is first point of contact. When the problem ultimately is identified as residing in Vendor B’s product, then what? It may be that the responsibility remains with Vendor A, but it also may be that Vendor A is only responsible for “Level 1 Support” and then you go to Vendor B for the difficult stuff. Ideally Vendor A stays involved and shepherds the issue through to resolution, sort of like a new car warranty. Inga’s Cadillac dealership did not build the car, but when the car breaks down, you take it back to Inga’s to get it fixed. Inga’s then takes care of the work required and is backed up by the manufacturer.

Taking the car analogy a little further, in terms of your contracted vendors, while you may know who is in the driver’s seat, you may not know who else is along for the ride. It could be an awesome two-seat Tesla roadster with two great vendors, or it could be the mud-covered SUV with a bunch of buddies all saying they work together just fine (and the driver is wearing really dark shades.) Due diligence in contracting pays off, and lack of diligence can really sting you later.

Vendors, please make it clear. You know best what is going on. Put it right out there.

After 20+ years doing this, I still remember a situation where an executive at a monster hospital chain felt something had been “snuck in.” In reality it was not, but the impression stuck hard and fast in this executive’s mind and we had to face extra scrutiny for several years to follow. Kind of like a dog that gets whacked by something at one of those birthday parties where twenty kids are running around screaming and things get zany and someone hands a whiffleball bat to the kids for the piñata. Anyway, the dog gets whacked (accidentally, of course) and never forgets the kid that did it. Don’t be the kid with the bat!

Tangential issue: get a warranty that states no other software is required, from your prime vendor or any other vendor, for operation of the software products being licensed. If other software is required but not included, require a listing in the agreement of all such products. Failure of your prime vendor to include something on this list should mean the vendor has to pony up and pay for it. That will bring all the fine details right to the top.

Finally, once you get everything above all set, make sure that all your hard work does not blow away in the wind because a vendor subcontracts work or assigns the agreement to another vendor. Include provisions prohibiting assignment or subcontracting without the customer’s agreement. That way you know what you are getting, from whom you are getting it, and that things will stay that way unless you agree otherwise.

Please take care in your interpretation of this article. I have been involved in countless good situations involving multiple vendors and very happy customers. When the provider does get a good prime vendor that truly takes on its role, you win. No question it works well in the right situations. My point is to be diligent and try to avoid bad situations by at least having good contract language on your side. The combination of a poorly performing vendor and weak or lousy contractual support will really ruin your day.

Big takeaways:

  • Contract language, warranties, and obligations should be consistent as applied to all products and vendors involved, even if designated to a prime vendor. Watch for disconnects in supporting language.
  • The contract should map out clearly the support chain and obligations of the vendors involved, again, even if designated to a prime vendor.
  • Require listing all software required for operation of the products being licensed and obligation for the vendor to provide whatever they failed to list.
  • Prohibit assignment and subcontracting by the vendors without your consent.

This article is intended to provide general advice and is not by any means exhaustive on the issues or language required and must not be taken as specific legal advice. Hopefully HIStalk readers enjoy the presentation and take away a valuable lesson or two.

William O’Toole is the founder of O’Toole Law Group of Duxbury, MA.



HIStalk Featured Sponsors

     

Currently there are "2 comments" on this Article:

  1. Great advice written in a way the lay person can understand and put to use, thank you! With the development approaches that have existed since client-server architectures really came to reality, embedded components (ex: image viewing controls, chart controls) are a fact of life. As programming languages and frameworks continue evolve (ex: new calls, new languages requiring a new wrapper, 32-bit vs. 64-bit), these embedded components need to keep-up. This has been a repeated challenge that I have seen and there are many loop holes that some vendors choose to wiggle through.

    The controls also can become a major security risk. I haven’t been able to get my head around that one. Do you believe that Business Associate Agreements (BAA) are now required with those vendors embedding systems or controls or that the BAA language with the primary vendor needs to change to take this into account?

  2. To Art_Vandelay:

    The BAA issue will depend on whether or not the other vendor (the non-prime vendor) will access patient information. If not, and all implementation and support rests with the prime vendor, then no BAA needed. But if the other vendor will access patient information, most likely for support issues, then yes BAA obligations exist. Basically under HITECH requirements the prime vendor must require its subcontractors to agree to BAA protection provisions.

    And thanks for your thanks!







Text Ads


RECENT COMMENTS

  1. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  2. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  3. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  4. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

  5. Yes, Meditech will talk your ears off about Expanse. There are multiple factors at play here which undercut both Meditech…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.