However, before we start dissecting the definition of the Cloud, let's agree on the definition of some basic building blocks of the model.
These definitions are used through the remainder of this article with the specific meanings described above. Just to be clear, for our purposes, a Subscriber is either a covered entity (CE) or a business associate (BA). A Provider is a third party vendor that makes one or more Services available to Subscriber on the Cloud. A Provider may also be a BA (e.g. an EHR vendor).
It's important to maintain clarity with respect to this terminology because there are often more parties involved in the delivery of a Service on the Cloud than is apparent on its face. For example, an EHR vendor that provides a Service (i.e. application) on the Cloud likely contracts with a Host for platform and infrastructure services.
Let's use a Cloud EHR vendor for the remainder of this article. The EHR vendor in this example would clearly be a BA of a CE utilizing its Service, and from a BA Contract perspective, that may be the only contractual relationship that the CE needs to enter into. However, from a due diligence and data protection perspective, the CE must be prepared to ask the BA questions regarding what other third parties are involved in the delivery of its Service. In this example, the CE's PHI may actually be stored on servers that the BA leases from a Host.
According to NIST there are three Cloud service models. Which are as follows:
For the purposes of this article we are only referring to the Software as a Service (SaaS) model. Most CEs (except perhaps for the largest) will use this model exclusively when accessing one or more Services. The SaaS model is the one in which a CE (i.e. Subscriber) has the least amount of control. Therefore, this is the model that produces the most data protection risks (and liability).
For the purposes of this article we are only going to consider the Public Cloud. If you get grounded regarding the data protection issues surrounding the Public Cloud (and get familiar with the technical mumbo-jumbo), then you will be able to make sense out of the other possible configurations.
The lost medical records disaster that occurred during Hurricane Katrina was at least as bad as what happened to the legal industry, although the former has gotten a lot less press in the aggregate. Here we are using Katrina as a metaphor for a disaster, either natural or man made. As discussed below, many disasters that are likely to occur at the intersection of healthcare and cloud computing will be caused by human/machine error. However, whatever the cause of the disaster, if you lose access to your PHI (even temporarily) it's going to be a bad day. If you permanently lose access to your PHI, for whatever reason, then you will almost certainly be facing significant reputation loss and serious legal liability.
For the remainder of this article let's assume that a CE is evaluating SaaS vendors to host its EHR system. First of all, we need to stipulate that any SaaS EHR vendor selected will be a BA of the CE and, therefore, a Business Associate Agreement will be required between the parties. Given that, what kinds of questions should the CE be asking, and what other terms and conditions should be included in the agreement?
Under the HITECH Act, the first question to be asked of a BA (any BA) is how are they complying with the HIPAA Security Rule? We would advise all CEs to ask for visible demonstrable evidence that the BA is in compliance, including a review of HIPAA/HITECH compliance policies, processes and tracking mechanisms. In addition, a CE is going to want to include those provisions of the HIPAA Privacy Rule that the BA should comply with, given the nature of the work that the BA is performing on behalf of the CE. For a SaaS EHR vendor, that likely includes most, if not all, of the substantive sections of the Rule.
A subset of the questions a CE should be asking are as follows:
1) What are you doing with respect to redundant co-location in order to ensure us that there is a low probability that two simultaneous catastrophic events will leave us completely vulnerable to losing our PHI for an extended period of time?
This is essentially a more specific way of asking what your disaster recovery plans are. Many co-location facilities will indicate that they have redundant electrical supplies, cooling, Internet connectivity, etc. These are obviously all very good things to have but if the entire facility gets wiped out by a disaster, then where would you be? The requirement is redundant co-location facilities the are geographically dispersed. Sure this is going to cost more, but how much is your PHI worth?
2) Assuming that you have redundant co-location facilities, how long would it take to "failover" from the primary to the secondary facility?
Failover is an information technology term of art that can mean recovery under a number of scenarios. Here the intended meaning is moving the application and its data from the primary co-location facility to the secondary co-location facility, with all the appropriate Internet DNS addresses being resolved correctly as required. If there was real time mirroring occurring between the facilities, then theoretically the "failover" would occur within minutes instead of hours or days.
In most cases the EHR SaaS vendor is not the business entity (i.e. "Host" from the introductory definitions above) that is providing the infrastructure to effectuate the kind of failover described above. This requirement would have had to be written into the contract with the EHR SaaS vendor, which in turn would have had to contract with the Host. As you can see from this example, technical complexity leads to legal/operational complexity. In any case, if you as a CE cannot tolerate days worth of downtime (we don't know any CEs that could) then you had better ask these questions and get satisfactory assurance from onset.
3) If there is a contract dispute, or I (as the CE) simply want to terminate my contract and switch vendors, how do I get access to my data?
How you get access to your PHI is an important consideration under a number of potential scenarios (e.g. disaster recovery, bankruptcy, etc.) but here we want to focus on a contractual dispute and/or voluntary termination. Once you have committed to go with a EHR SaaS vendor you have made a decision to turn over one of your most important assets to a third party business associate. As long as you have performed the required due diligence and remain satisfied with the business relationship, then the reality of less control remains unproblematic. However, what happens when you want to terminate the relationship and (for reasons you can justify) you are behind in your subscription payments? Here there is a good chance that your data might be held hostage until you become current in your payments. In other words, your former trusted partner now has an economic gun to your head. What do you do?
One solution is to insist on terms and conditions wherein your data is replicated, either real time or daily, to servers under your control as a backup. Sure there will be extra cost for this service, but at least you have assurances that you could get at your data should the need arise. But "getting at your data" is not nearly enough to solve the business problem you now face for the following reasons:
In short, turning over your PHI to an EHR vendor is a serious commitment that needs to be thought through with a high degree of rigor, anticipating as many potential (though hopefully not probable) business/legal contingencies as possible.
Healthcare providers will continue to move to the Cloud because cloud computing economics are too compelling to ignore. However, providers are well advised to do so only after performing rigorous due diligence and becoming educated as to the risks as well as the rewards of the Cloud.