Cloud Services, Cloud Bubbles, Conduits and Business Associates – Updated January 25, 2013

PLEASE SEE THIS POST FOR MORE CURRENT INFORMATION:  Do the HITECH Rules Really Make All Healthcare ASPS and Cloud Services Providers Business Associates?

I’ve been thinking more deeply about healthcare IT, PHI and the cloud. I now have clients who are are building it in to their processes, and I’ve become convinced me that it’s really the only way to afford the computing resources needed for some truly valuable (not just valuable as in profitable, but treatment-valuable) applications. And as a lawyer, it’s not really my job to tell my clients they can’t take this kind of risk:

Decisions like this are in the final analysis the fiduciary responsibility of the officers and board of the organization, and the role of both lawyers and security professionals at this level is to provide these officers and directors with the information and professional advice they need to make them.

I’ve had a look at these issues before, both on-blog and off, but it’s time to revisit some of my thinking.

When Is a Cloud Services Provider a Business Associate or HIPAA Subcontractor?

In most (probably almost all) of the healthcare IT discussions I’ve seen about using the cloud, the big topic seems to be whether or not a  cloud services provider is a Business Associate (or HIPAA subcontractor of a Business Associate). And many cloud services vendors have been stating their positions on this issue, as they should. For example, Microsoft has announced that it has “embedded” the Security Rule safeguards in Azure, and will enter into its form of Business Associate Agreement with Covered Entities – though I note that I haven’t seen any Microsoft statement that they in fact are a Business Associate.

On the other hand, Amazon implies that it is not a Business Associate, because its page discussing HIPAA compliance refers to use of its platform for “HIPAA-compliant” applications, without referring to Amazon as a possible Business Associate. I do appreciate their analysis of their services as a “shared responsibility environment,” since it’s consistent with my own analysis of the cloud services provider/client relationship, but their analysis also supports an implication it is not a Business Associate.

The thing is, coming at this from the perspective of a client of a cloud service, I actually don’t care whether the cloud services provider characterizes itself as a Business Associate or not. Sure, if it a identifies itself as a Business Associate, I will insist on a Businesss Associate Contract, and if it doesn’t, I might not. But what I really care about is, what does the cloud services contract actually allow the cloud services provider to do with Protected Health Information?

Whether or not a given cloud services provider is a Business Associate depends on whether it meets the regulatory definition, which is that the entity obtains, uses or discloses Protected Health Information on behalf of a Covered Entity.  (Or, if it obtains it from a Business Associate, it’s a HIPAA subcontractor.) If it does, it is; if it doesn’t, it isn’t.

When Is a  Cloud Services Provider Like a Conduit?

For technology services in particular, OCR has developed the useful  concept of the “conduit:” An entity which “transports information but does not access it other than on a random or infrequent basis as necessary for the performance of the transportation service or as required by law.” The paradigmatic conduit is the postal service, which can deliver mail including Protected Health Information, but whose carriers and officers are legally prohibited from opening the mail, except in case of accident (e.g. damaged mail) or if required by law (e.g. under a warrant).

In the HITECH Omnibus Rule NPRM OCR confirmed that conduit status is a fact-based determination, not one established (or not) by contract of the parties (note that this is in the context of a discussion of subcontractors as possible Business Associates):

Even though we use the term ‘‘subcontractor,’’ which implies there is a contract in place between the parties, we note that the definition would apply to an agent or other person who acts on behalf of the business associate, even if the business associate has failed to enter into a business associate contract with the person.

. . .

The only exception to this proposed rule is for subcontractors which are “conduits,” i.e., “data transmission organizations that do not require access to protected health information on a routine basis” and “do not access the information other than on a random or infrequent basis[.]”

In other words, like the postal service the provider must (1) not have a “routine” need for access to Protected Health Information, and (2) in fact must not access such information “other than on a random or infrequent basis” – something like by accident or infrequent legal process, like the postal service.

Now, very few cloud services are really transmission services – i.e., paradigmatic conduits. We’re really talking about data processing and storage, with some ancillary transmission. But the same concepts apply: If a cloud services provider hosts Protected Health Information processing and storage applications, but does not “routinely access” the data as part of its services, and in fact doesn’t access the data other than “randomly/infrequently” or if legally required, it’s not a Business Associate or HIPAA subcontractor. Maybe it’s not technically a conduit, either, but the same analysis which distinguishes a conduit from a Business Associate, distinguishes cloud services providers which are Business Associates from those which aren’t.

Maybe we should call them “cloud bubbles?” It might have some negative connotations for investors, but has a better ring than “bubble clouds” (which are, however, kind of cool.)  So, for purposes of this post, anyway, let’s call a cloud services set which does not entail routine access to Protected Health Information by the cloud services provider, which also at most access such information on an infrequent/random/legally required basis, a “cloud bubble.”

HIPAA-Compliant Contracting with Cloud Services Providers.

If I’m contracting with a cloud services provider which represents that it is not a Business Associate, and therefore must be providing a “cloud bubble,” I can satisfy the first prong of the demonstration that it is not a Business Associate by a contract provision prohibiting the cloud service provider from having access to my client’s information, period. Unless I implement client-controlled encryption (see below) I probably do want to allow for strictly limited, strictly conditioned and disclosed accidental or unavoidable access, and the cloud service provider might want to insist on its right to access in response to legal requirements (about which I would want to have notice and an opportunity to challenge, unless notice is prohibited by law.) I would also want the cloud services provider to represent that it would comply with these prohibitions, in support of satisfying the second prong.

With these parameters, I think I would be satisfied that we had an effective “cloud bubble,” and that my client would not need a Business Associate Contract (or HIPAA subcontract) with the cloud services provider. If the cloud services provider then proceeded to have non-random and/or frequent access to my client’s Protected Health Information, the cloud services provider would be in breach of contract, and quite possibly in violation of federal and perhaps state laws pertaining to unauthorized access to computer systems and resources. Further, the cloud services provider won’t have crossed the line into Business Associate (or HIPAA subcontractor) status, because access in violation of the contract is clearly not “on behalf of my client,” so my client isn’t in breach for lack of a Business Associate Contract.

On the other hand, if I’m contracting with a cloud service provider which represents that it is a Business Associate,  I would want still need and want  to define very carefully the reasons it could have access to Protected Health Information for purposes of its services, and otherwise (as with a “cloud bubble” provider) would still want to allow othersie only for strictly limited, strictly conditioned and disclosed accidental or unavoidable access; and the cloud service provider would probably still want to insist on its right to access in response to legal requirements, about which I would still want to have notice and an opportunity to challenge, unless notice is prohibited by law. And if the cloud services provider proceeded to have non-random and/or frequent access to my client’s Protected Health Information, the cloud services provider would be in breach of the Business Associate Contract, and just like the conduit provider quite possibly in violation of federal and perhaps state laws pertaining to unauthorized access to computer systems and resource.

So I’m not sure, in the final analysis and from the client’s point of view, that I care whether or not a clould services provider wants to represent that it’s a Business Associate or not.  Either way, the key point is to define permitted and prohibited access to, uses and disclosures of Protected Health Information by the cloud services provider, from none/accidental/legal for conduits, to whatever is necessary and appropriate for services which make the cloud services provider a Business Associate.

It’s worth noting, by the way, that I’ve used the kinds of provisions I just discussed for years in application services provider (ASP) and related kinds of contracts for years. For these purposes, anyway, the magic word “cloud” doesn’t change the analysis.

Conduits and Encryption.

I have heard it argued that what’s actually necessary to establish conduit status, is to encrypt the data stored in the cloud, and not let the cloud service provider have a key. I think this is incorrect, and confuses a Security Rule question with an overall regulatory status question. Business Associate/HIPAA subcontractor status, as discussed above, doesn’t turn on whether or not a party can access Protected Health Information, but whether it does so under the authority of a Covered Entity or Business Associate.

The Security Rule, on the other hand, has a number of access control requirements in particular which should help prevent or detect unauthorized access by a cloud services provider. Obviously, robust encryption with no key access for the cloud services provider would prevent unauthorized access, but it isn’t a requirement for conduit status and could materially slow some valuable applications. Since encryption of data-at-rest is an addressable specification, the basis for any decision to forego encryption and for selection of compensating controls (e.g. good monitoring processes and practices) would need to be well documented in any case.

I would also want to review information about the cloud services provider’s processes and practices, since my client will be crucially dependent upon them. But again, this is a Security Rule issue, not a regulatory status determinant – and it’s also the same kind of issue you get with ASPs which operate joint computing environments.