Why Us?

We know the law and we know the web.

We help companies safely and securely do business on the web.

HITECH / HIPAA Newsletter May 2012

However, before we start dissecting the definition of the Cloud,  let's agree on the definition of some basic building blocks of the model.

Basic Definitions

  • Subscriber: means an organization that maintains a business relationship with, and uses Service(s) from, Providers.
  • Service: means, when used without a qualifier, Software as a Service (SaaS). See Service Models below.
  • Provider: means an organization responsible for making a Service available to Subscribers.
  • Auditor: means an organization that conducts an independent assessment of cloud applications, information system operations, performance and security of the cloud implementation.
  • Host: an intermediary organization that provides platform and infrastructure services to a Provider.
  • Carrier: an intermediary organization that provides connectivity and transport of cloud services from Providers to Subscribers.

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.

Service Models

According to NIST there are three Cloud service models. Which are as follows:

  1. Software as a Service (SaaS): The capability provided to the Subscriber is to use the Provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a Web browser (e.g., Web-based email). The Subscriber does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.  
  2. Platform as a Service (PaaS):The capability provided to the Subscriber is to deploy onto the cloud infrastructure Subscriber-created or acquired applications created using programming languages and tools supported by the Provider. The Subscriber does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.
  3. Infrastructure as a Service (IaaS):The capability provided to the Subscriber is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The Subscriber does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

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).


HSGLogoFacebook, Google, Twitter and GroupOn are all examples of

SaaS applications made available on the public cloud.


Deployment Models

  1. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.  Facebook, Google, Twitter, and GroupOn are all examples of applications (SaaS) made available on a public cloud.
  2. Private Cloud: The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. Many large healthcare providers have their own private clouds.
  3. Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.
  4. Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

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.

Protecting Your Data: Katrina Proofing your PHI on the Cloud?

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:

  • the data is likely to be in a database structure that is incomprehensible to you without guidance from your partner (who may not be inclined to provide timely guidance under this scenario); and
  • even if you have the data, you don't have access to the application that makes it visible and functional (remember this is a SaaS application that resides on the Cloud) as you transition to your new vendor (which is likely to take some time given that you have to upload your PHI to the new system and train staff, etc.).

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.


Contact us today