Health IT and Electronic Health Activate your FREE membership today |  Log-in

Community Blog

Sep 27 2011   11:30AM GMT

Key attributes of solid contracts and SLAs for cloud hosting in health care



Posted by: Jenny Laurello
Chris Witt, Cloud, Cloud computing, Contracting, Data storage, HIPAA, Service Level Agreement (SLA), SLA

By Chris Witt, President and Co-Founder, WAKE TSI

In my earlier entries, we discussed the pros and cons of using public cloud computing in the delivery of health care computing services and the key elements for executing a move to the public cloud. Somewhere in the process you will select a vendor that best aligns with your strategy. The next step in this vendor relationship is to negotiate the contract. Contract negotiation is like sausage making in that you want the final product but you don’t want to see how it is made.

There are a lot of similarities in a cloud contract with other contracts that you have negotiated with your vendors. If you currently employ data center co-location or managed services, you will see many parallels with cloud services.

Now for the disclaimer – I am not an attorney and nothing written here should be viewed as legal advice. These are observations we have assembled while working with many of our clients. You should engage your corporate council early in the process. They will prove to be invaluable.

Now let’s look at some of the highlights:

  • HIPAA – This might seem like an obvious area, but it requires some specific attention. Due to the nature of cloud computing, it can be difficult to know where your data is and who has access to it. Ultimately, you are on the hook to secure the data and be able to audit access. You want to ensure your vendor will facilitate this logging.
  • Force Majeure – Most standard contract language makes it far too easy for a vendor to declare Force Majeure. Personally, I would not recommend that a client go into anything less than a Tier 3 data center. It should take a catastrophic local event to bring down the data center. Also, your cloud instances are portable and should be replicated. A primary reason you move to the cloud is for the inherent resiliency. If you are not leveraging this, why not?
  • Services – Make sure the contract clearly spells out the required services provided by the vendor and pre-negotiate the optional services. The contract should also cover implementation and the roles and responsibilities of each party. Do they include backup? Archiving? What happens if you need a restore?
  • Service Level Agreement (SLA) – This is where you document your expectations. The SLA components should directly relate to the requirements you put together earlier in the process. There should be no surprises here. These are items you should have been discussing all along with your vendor. If the vendor cannot provide an SLA you are comfortable with, find a new one. There are plenty of them out there.
  • Penalties – This is where it gets a little dicey. Vendors hate penalties – Clients never think they are punitive enough and vendors think they are excessive. To be fair, penalties are not there to ensure reimbursement of any costs due to not meeting an SLA. They are a deterrent to encourage the vendor to do the right thing.
  • Breach – You need to determine the situations you could potentially be put in where you would want to end the contract prior to the end of the term. This will include various egregious actions by the vendor, but also should include the inability to maintain SLAs. As I mentioned earlier, penalties are not going to cover all your losses. You should include language for breaking the contract if vendor has a number of SLA failures during a period of time. Our favorite is three events in a single month.
  • Termination – You carefully plan how you are going to migrate your computing services to the cloud. You need to pay just as much attention on how you would get them back in case you part ways with the vendor. There is a very good chance that if you are parting ways, it is not amicable. The contract should be specific on what the vendor and client responsibilities are, and specify timelines for critical activities. Another area you may want to consider is change of ownership or a bankruptcy. If the vendor is acquired or goes broke, what are your rights? I always address this by encouraging the vendor to give the client a termination option. This is especially important if you dislike the new ownership.

There are numerous items that make up a good contract, many of which are basic and not included here. While negotiating the contract, you need to keep visualizing the worst possible situations you could be put in. Your ultimate goal is to protect the organization in case there is a problem. But remember, the contract is only a piece of paper and should be one component of your overall continuity strategy. So, pay attention to the details and enjoy the sausage.

For more information, please visit http://waketsi.com.

Comment on this Post

Leave a comment:

Jomostarke  |   Sep 28, 2011  1:00 PM (GMT)

Good post. To the “Termination” language I would add a clause about “source code escrow”, very specifically outlining your rights to the code in case the vendor goes bankrupt or is acquired.


 

CWitt  |   Sep 29, 2011  2:08 PM (GMT)

Jomostarke,
Your point is dead-on when entering into a SaaS relationship; especially a proprietary one that is housing your PHI. The data does not do you much good without the software to access it with. Thanks for the comment.
CW


 

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: