Legal Issues in Cloud ComputingAttorney Outlines Key Factors to Consider
In an interview (transcript below), Marilyn Lamar, a partner at Liss & Lamar, advises those considering using remotely hosted applications to:
- Make sure the cloud computing vendor adequately addresses confidentiality, data integrity and availability issues.
- Specify in the contract how the vendor will preserve and produce information for e-discovery requests in court cases.
- Include extra security details in the business associate agreement, especially related to disaster recovery provisions. She points out that under proposed modifications to HIPAA, as called for under the HITECH Act, vendors serving healthcare organizations must comply with the HIPAA security rule.
- Make sure the vendor uses at least the same level of encryption as your organization. "You don't want the third party to be the weak link in the chain," Lamar says.
- Consider the risks related to where the vendor's data center is located.
- Make sure, under the terms of the contract, that your organization is always able to retrieve data whenever it wants it, not just in case the vendor goes bankrupt.
- Ensure the contract specifies that all security provisions will continue to be carried out if the vendor is taken over by another company.
Lamar has more than 20 years of experience in corporate and information technology law, including electronic health records, health information exchanges, personal health records and HIPAA and HITECH Act privacy and security issues. Her practice includes a broad range of outsourcing, licensing and other technology transactions on behalf of hospitals, health plans, health information exchanges, group purchasing exchanges and technology companies.
The attorney is a director of the American Health Lawyers Association and serves on its quality council. She formerly was a capital partner at McDermott, Will & Emery LLP, where she chaired the health law information technology practice group.
HOWARD ANDERSON: So what are the most critical security risks that should be considered before implementing cloud computing? And how do those risks differ based on the cloud computing model that is used?
MARILYN LAMAR: First I should say that my comments are from a legal perspective only because I am not an IT security professional. And this is general information, not specific legal advice, that would be tailored to your particular situation. ...
There has been a lot of publicity around cloud computing; some people might say there has been a lot of hype around it. And we wonder how it is really different from things we have seen in the past, ASP-type models or even back to older variants of outsourcing, timesharing and that sort of thing.
So I think it is helpful to look at the gradations of how much of your services you are turning over to the cloud computing vendor. I think the essential characteristics of cloud computing include the fact that it's on demand, it is self-service to some degree, and it is somewhat elastic in terms of how much you want to have. And that is a big attraction to it -- that you don't have to buy perhaps all the hardware that you otherwise would be buying.
You have got access to a shared pool of computer resources that can be configured to suit your needs, whether that's a network or something more complicated than that. And then the pricing is based on some sort of measurement of your actual usage. And all of that is very attractive to people.
So within that model, generally, people will talk about software as a service, and there the customer has probably the lowest level of control. They are using the vendor's applications running on the vendor's hardware and other infrastructure elements. So at that level, you have probably given up the most control as a user, as opposed to things that are a little bit less in terms of turning over control, such as the customer deploying its own applications or perhaps third-party license applications on the vendor's infrastructure.
And then you have a third gradation, where the customer really controls the operating system, storage and applications and maybe even the firewalls, but the vendor is providing just the infrastructure, just the hardware.
So depending on where you are, you want to be clear because your management and others in your organization may think of something different when you are talking about cloud computing. It could be just a private cloud, where it is really only being used by your organization, versus a public cloud that's being used by a lot of different customers. And for most smaller physician practices or even some hospitals, they are probably looking at a public cloud situation to get the economies of scale and to get good pricing from a major cloud computing vendor.
So in terms of what security issues I think should be looked at, from my perspective as a lawyer, you want to make sure that you are addressing the basic HIPAA elements of security -- those being confidentiality, integrity and availability. The availability comes up because, of course, it is only going to be accessible via the Internet for the most part and people have to get comfortable with that.
I think another aspect of that is you no longer have the knowledge base in-house to the same degree as you did before. It is no longer a matter of necessarily being able to knock on the IT department's door and say, "Please fix this" or "What's wrong with a particular server?" A lot of times, most of data will be off site and you are just more dependent on a third party. So people have to get comfortable with that.
With respect to confidentiality, you certainly have all of the HIPAA privacy issues to worry about. ... State laws as well as HIPAA and HITECH Act that are requiring more and more disclosure, including notice to the individuals when there has been some sort of a security breach. So you are going to have to worry about both federal and state compliance if there has been a security breach.
But I don't mean to imply that cloud computing is a bad solution. In fact, for many smaller physician practices and perhaps even some smaller hospitals, the discipline and rigor of the data backup and disaster recovery could be a lot stronger with a good cloud computing vendor than the individual organization could do for itself.
The last point I would make in this segment is to really go into a lot of due diligence at the technical level about how strong is the separation between customers, how strong are the firewalls, or whatever other separations they are going to have in this general offering -- assuming there is going to be more than one customer operating on the very server that you are going to be using. Because you don't want to have some sort of information leakage or have other customers have access to your data.
ANDERSON: What are some of the most important legal issues involved, such as how to retrieve remotely hosted data to comply with a discovery request or how to prove the integrity of the data?
LAMAR: Electronic discovery has gotten a lot of attention. Companies of all types are finding that providing information in a litigation context or an arbitration context is very time-consuming and expensive. A lot of cases that are out there that are not even in healthcare -- that involve employment discrimination or things like that -- are actually being settled at an earlier stage because it is so costly and overwhelming to be producing all sorts of e-mails, let alone the types of records that we could be thinking about with respect to e-health sorts of applications or electronic health record applications.
The federal courts, and some of the state courts, have specific rules regarding e-discovery because they realize it is just not the same as producing paper copies of things. And those rules require IT professionals to get involved very early with the lawyers and with people defending the case or prosecuting the case to outline the scope of what is going to be discoverable and to put electronic and other restrictions in place so that things that might be getting deleted in the ordinary course do not get deleted on that schedule because they are now evidence potentially in litigation.
So if you think about how you are going to administer this in the context of cloud computing, you really want to get a good working understanding and document that in your contract with the vendor to say exactly what will happen if there is some sort of litigation discovery request where we have to preserve and produce this information. How much of the vendor's resources are you going to need at any particular point in time? And can they wall off some information for litigation, what is known as putting a litigation hold on the data? And just how will you administer that?
To the other question of how to address integrity of the data, that may also require working with your risk management department and counsel. ... Things that are probably pretty standard in the cloud computing environment, such as reducing storage space because we are going to remove data that might be duplicated someplace else, may make it more difficult for someone to testify on behalf of a covered entity (the customer) that nothing happened to the data and it is, in fact, the record.
Opposing counsel is becoming more and more savvy about this. And if they can create enough question in the jury's mind that the data or the record has been tampered with or is not completely positive as to having integrity, then they may be able to chip away at the covered entity's or hospital's position and make them look bad. Sometimes in litigation, such as in malpractice cases, that is enough to sway someone to perhaps influence the verdict or influence the amount of money that is paid.
ANDERSON: Companies remotely hosting clinical software are considered business associates and must comply with HIPAA. Are there specific security provisions that should be spelled out in the business associate agreement with these vendors beyond what you would normally have in such an agreement?
LAMAR: Good practice would suggest that we would go into more detail than we have. Business associate agreements have become fairly routine in many ways. ... In my view, we really would benefit by having the appropriate technical folks take a good, hard look at what a vendor is doing, particularly in cloud computing, regarding disaster recovery, for example. Has there been a SAS 70 audit? Is there periodic testing, and would the customer be able to review the results of that testing? On the other hand, how disruptive would the testing be potentially to the customer's day-to-day operations? So that is just one example of what doesn't get a lot of attention in your standard business associate agreement.
The HITECH Act now puts direct obligations on business associates, almost to the same degree as covered entities. Business associates have legal liability, and you probably should be making some reference to HITECH in those agreements to say that the business associate is now directly covered by those rules. But in terms of the real operational side of it, I think people really should go a bit above and beyond what is in the typical business associate agreement to look at what are the unique security risks of the situation.
ANDERSON: What questions should potential users ask about how the cloud computing company hosting the applications uses encryption?
LAMAR: Are they using the same levels of encryption as the customer? Because if you are outsourcing to some degree, which is really what cloud computing is, you don't want to have that third party be the weak link in the chain. ... There also are now more specific obligations to give notice to people if there has been some sort of a security breach. And there's an exception to that reporting requirement in the HITECH Act if the data has been encrypted at a level that meets the then current standards. ... It gives you an "out" if there has been a laptop stolen, or a thumb drive that has gone missing if the data has been encrypted to that standard because you don't have to report it. ...
The flipside of the encryption issue, though, is if they were encrypting to such a degree that it impacts adversely the availability of the information. Because, of course, the data is critical to patient care, and you wouldn't even want to be without it for financial reimbursement for very long.
You really need to understand what the cloud computing vendor is doing regarding encryption and make sure that you think that that will give you a sufficient level of availability.
ANDERSON: What should potential users ask about how data will be backed up and about how the vendor handles security in its data center?
LAMAR: Ask about where the data is located, in terms of the country. Some cloud computing vendors have significant operations offshore because it is so much cheaper to be doing things offshore than in the Untied States. And hospitals and physicians may or may not be comfortable with that. And not every offshore country is the same.
I have had clients that are completely comfortable if they know the data is in the United States or it's in the vendor's well-established facilities in India, for example, where they know that they have been doing it for a number of years and they are very comfortable with that country's risk level. We have all got some threats, unfortunately, of terrorism no matter where we are. But a hospital may feel much more comfortable with data in India than they would in a country such as Pakistan, which isn't all that far away.
Another factor to consider would be a region that is prone to earthquakes. There are a lot of things to think about in terms of whether the data goes offshore and, even in this country, where it is stored.
So I would start with that, and then really delve into the disaster recovery plan: Is it tested? Have they shared with you a SAS 70 report? How often is it tested? Can you get access to the test results to find that out?
So I think all of those things are really critical, especially given the complexity of cloud computing, where the data may be moving from time to time, perhaps even internationally.
ANDERSON: What kinds of provisions should be written into the contract with a vendor about what happens to the data if a company goes bankrupt or merges with another firm?
LAMAR: We have unfortunately found that some of the cloud computing vendors use standard contracts ... that say the data becomes the property of the cloud computing vendor, which is possibly an outrageous result in any set of circumstances but particularly in healthcare, because there is so much concern about data privacy and data ownership. Data ownership is an open question in a lot of places concerning whether it is the property of the patient or whether perhaps it is the property of the healthcare provider -- but we certainly don't want it to become the property of the vendor. That would seem to fly in the face of many things we almost take for granted in HIPAA and business associate agreements, so you just don't want to have to fight that fight.
I would suggest that the standard contract should state that the customer should always be able to obtain its data whenever it wants it and not just in the event of a bankruptcy or a termination of the agreement. And people still do have fights with their vendors, unfortunately, where the vendor is holding the data hostage.
And when we say get access to your data, you want to be able to get it in a standard format that is going to be usable to you and is going to be something that you can migrate to another vendor or bring it back in house. So if it is somehow tied into a proprietary format of the cloud computing vendor, perhaps their particular software, you want to make sure that you can use it going forward without worrying about that.
The bankruptcy issues are particularly challenging because of the over-arching spirit of the bankruptcy law, which is to try to give bankrupt companies every chance to recover and come out of bankruptcy and survive. And that can lead to almost an odd result. Bankruptcy law, for example allows for a bankrupt vendor to cancel any kind of contract that is still operating and performance is still owed on both sides.
So, for example, a services agreement where you are still paying money and the vendor is still providing services would be what is considered an executory contract, and the vendor who is bankrupt could terminate that contract because perhaps it wasn't economically profitable to the vendor. Or it could just be sort of a bargaining chip that we are going to terminate this because we have the right to under bankruptcy law and we are going to then use that as an excuse to renegotiate and ask for a longer term or charge you more money. ...
So one of the best ways to minimize this risk, as a practical matter, is to be careful who you are doing contracts with in the first place. If it's a publicly traded company, that gets easier because you will have access to their financial information through the Securities and Exchange Commission. ... But you also have to keep monitoring on an ongoing basis whether they are still in financial good health. Be mindful of the fact that you may have to move to another vendor. This may sound biased in favor of the bigger players, and I don't mean it to. It is just a fact of life that companies are not all necessarily doing well, especially in this recession, and we have to be mindful of whether there are going to be financial problems with them.
In terms of mergers and acquisitions of vendors, you certainly would want to make sure contractually that the security requirements you have negotiated in your contract, and any kind of service-level agreements, will continue to be binding on a company that acquires it. ...
Sometimes you can get an early termination right if, in fact, the company providing the services now is acquired by someone or merges with someone who is one of your competitors. You see this in the insurance industry fairly frequently -- that they are happy to deal with a third party, but if that third party were acquired by a competing insurance company, then they really wouldn't want all of their information being hosted by a competitor.