Do the HITECH Rules Really Make All Healthcare ASPS and Cloud Services Providers Business Associates? – Updated January 27

Do the HITECH Rules Really Make All Healthcare ASPS and Cloud Services Providers Business Associates?

One of the key problem areas for application and cloud services providers to healthcare organizations is their status under HIPAA/HITECH:  Are they Business Associates? Or aren’t they?

I’ve discussed this for cloud services providers before here, and have to say my previous analysis has now been seriously affected by the HITECH Omnibus Rule and the accompanying official discussion of its interpretation. (For a guide to this rule please see my linked posts in the HITECH Business Associates Rule Tool, starting here.) In particular, my interpretation of the law, as it existed before the HITECH, was that “Business Associate/HIPAA subcontractor status . . . 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.”

I based this interpretation on the “conduit” concept, introduced by the DHHS Office of Civil Rights (“OCR”) in 2000, as well as an OCR “clarification” letter to Tindall Record Storage, a document storage company, from 2003. I therefore concluded that Protected Health Information hosted in the cloud did not have to be encrypted, with the keys unavailable to the cloud services provider, in order for the cloud service provider to avoid Business Associate status.

For good or ill, however, it appears OCR disagrees. In particular, the official commentary on the Rule can be interpreted to make any party hosting Protected Health Information as a service to a Covered Entity (or as a service to a Business Associate which is using it as a service ultimately for a Covered Entity – if that formulation is confusing, please read this) a Business Associate by definition, unless the Protected Health Information is encrypted and the provider does not have access to the keys.

(NOTE: I do understand that an OCR official apparently indicated that an entity which “maintains” – hosts, stores – even encrypted PHI for or on behalf of a Covered Entity (including soon indirectly through a Business Associate), even if the entity doesn’t have access to the keys, is a Business Associate because encrypted or not, it is “maintaining” the PHI. I was unable to attend the webinar where this was said and don’t know how the issue was presented, but this interpretation would be inconsistent with the interpretation atation in the preamble to the Omnibus Rule discussed in this post, and would be incorrect for the reasons discussed below. Since this was a comment at an educational event I won’t take this as the official OCR position and am willing to assume it was an error or mis-statement, or misunderstanding of the question. It would, however, be very helpful for OCR to issue a well-advised clarification. Now, back to our scheduled disquisition.)

The problem is that some services providers which don’t meet these criteria may not realize that their customers are using their services for such purposes, and therefore become Business Associates – and subject to all the obligations and liabilities that status entails – without notice. This could include cloud and application services providers, and even some ISPs.

The following analysis demonstrates the problem.

When Is a Business Associate Not a Business Associate?

The conduit concept was based on an analogy to the U.S. Postal Service, which transmits its senders’ information in sealed envelopes which it cannot legally open without a warrant, whose contents it otherwise only accesses in non-routine circumstances such as damage to an envelope. This analogy was introduced in the preamble to the 2000 version of the Privacy Rule, with minimal discussion and no real analysis. The only possible application it noted was to the “electronic equivalents” of the Postal Service, though the only specific example discussed (in very little detail) was electronic funds transactions.

The 2000 interpretation can be summarized as follows:

A “conduit” is defined as an entity which –

• Transports information including Protected Health Information for or on behalf of a Covered Entity, but
• Does not access the information other than on a random or infrequent basis,
  • As necessary for the performance of the transportation service, or
  • As required by law, where
• No disclosure of Protected Health Information to the services provider was intended by the Covered Entity, and
• The probability of exposure of any particular set of Protected Health Information is very small.

Subsequent guidance did not provide any additional insights or information. However, a 2003 letter to Tindall Record Storage clarifying “when a business associate agreement is required for a covered entity to enlist the services of a document and record storage company for purposes of storing [Protected Health Information]” seemed to indicate a comparable interpretation would be applied to data storage services:

We confirm that a business associate agreement is not required between a covered entity and a document storage company performing functions on behalf of the covered entity, where any protected health information released to the storage company is transferred and maintained in closed and sealed containers, and the document storage company does not otherwise access the protected health information. Neither is a business associate agreement needed when, in these circumstances, any access to the information is merely incidental. For example, a storage company may have incidental access to protected health information if a box becomes damaged and needs to be repackaged.

So how far should the conduit concept extend? Certainly It seemed clear that Internet services providers (“ISPs”) providing messaging services, as well as other kinds of “pure” message and transaction transmission services, fell within the concept. However, since 2000 there has been a proliferation of IT solutions in healthcare, from applications and services promoted by Congress and DHHS such as electronic health records and health information exchange, to improved, more cost-effective outsourcing including cloud-based and other application services providers.

In developing such services, or advising healthcare and technology companies which were developing them, as well as in a number of less formal venues such as specialist listservs, there have been fairly frequent discussions about this problem, since the question whether a given service was or was not a Business Associate could clearly have significant consequences. The factors used to define and justify the 2000 interpretation factors extended quite logically to non-transmission services which store, and perhaps to some which to a limited extent process, Protected Health Information, in addition to transmission services. Coupled with the Tindall Record Storage letter, there seemed to be good reason to believe the same analysis (if not necessarily the term “conduit”) should apply to some kinds of services which stored, and perhaps in some cases to some degree processed, data including Protected Health Information.

The 2010 Notice of Proposed Rulemaking for the regulations which became the Omnibus Rule mentioned the conduit concept only in passing, noting a change required by the HITECH Act:

. . . data transmission organizations that the {HITECH] Act requires to be treated as Business Associates are those that require access to Protected Health Information on a routine basis. Conversely, data transmission organizations that do not require access to Protected Health Information on a routine basis would not be treated as Business Associates.

There was no indication OCR was considering changing the 2000 interpretation.

There were 305 comments on the proposed rulemaking. The only comment from any specific technology company was from AT&T, which was principally concerned that use of its data transmission services not trigger Business Associate status. The Software and Information Industry Association was also concerned that Business Associate status would be triggered unexpectedly for some of its members, but provided no real details or meaningful description of technologies or arrangements be implicated. The HIMSS Electronic Health Record Association asked for clarification of the conduit concept, particularly criteria for determining “routine” versus “random or infrequent” access to Protected Health Information, and HIMSS also asked for clarification while providing somewhat detailed information about health information exchange models in particular.

Otherwise, there were 36 comments (almost 12% of all comments) from document storage companies, apparently principally or entirely hard-copy document storage, including their trade association. These comments were principally, and in most cases entirely, concerned with Covered Entity demands for indemnification against security breaches by such companies storing their records, and a number requested express extension of the conduit concept to such companies, as did a comment with respect to personal health records.

OCR declined to extend the conduit concept to document storage and related types of service. The Omnibus Rule itself does not specifically address this issue, but the interpretation in the preamble makes it clear the conduit exception is intended to be a narrow one which does not apply beyond data transmission services. In particular, this interpretation states that “data transmission organizations that do not require access to Protected Health Information on a routine basis would not be treated as Business Associates”, and that the conduit

. . . determination will be fact specific based on the nature of the services provided and the extent to which the entity needs access to Protected Health Information to perform the service for the Covered Entity. The conduit exception is a narrow one and is intended to exclude only those entities providing mere courier services, such as the U.S. Postal Service or United Parcel Service and their electronic equivalents, such as internet service providers (ISPs) providing mere data transmission services. [Emphasis added.]

The discussion the reiterates that the conduit exception “is limited to transmission services  . . . including any temporary storage of transmitted data incident to such transmission.” (Emphasis added.)

On the other hand, “an entity that maintains Protected Health Information on behalf of a Covered Entity is a Business Associate and not a conduit, even if the entity does not actually view the Protected Health Information.”  This distinction is stated to be based on the

. . . transient versus persistent nature of that opportunity [for the entity to view the Protected Health Information. For example, a data storage company that has access to Protected Health Information qualifies as a Business Associate, even if the entity does not view the information or only does so on a random or infrequent basis. Thus, document storage companies maintaining Protected Health Information on behalf of Covered Entities are considered Business Associates, regardless of whether they actually view the information they hold.

For this reason the definition of Business Associate was expanded to clarify that it includes entities which “maintain” Protected Health Information on behalf of a Covered Entity.

This does not appear to mean that OCR interprets the rules to make all record or data storage services Business Associates automatically. Rather, the discussion seems to track (without mentioning) the discussion in the Tindall Record Storage letter, and it extend it to digital records.

In particular, the discussion in the preamble to the Omnibus Rule states that “a data storage company that has access to Protected Health Information (whether digital or hard copy) qualifies as a Business Associate, even if the entity does not view the information or only does so on a random or infrequent basis.” (Emphasis added.) For electronic Protected Health Information, the Security Rule provides a definition of “access” as “the ability or the means necessary to read, write, modify or communicate data/information or otherwise use any system resource.” We might call a service which meets these criteria a “sealed service.”

Criteria for a “conduit” and a “sealed service” might therefore be summarized as follows:

1.  A “conduit” is an entity which –

a.  Provides a data transmission service to or for Covered Entities and/or Business Associates,

b.  Which is used to transmit Protected Health Information for or on behalf of such entities, which either –

                                                              i.      Does not entail data storage, or

ii.      Entails “transient” but not “persistent” data storage, and

c.  Which either –

                                                               i.      Does not entail access to Protected Health Information by the services provider, or

ii.      Entails only “random” or “infrequent” access by the services provider.

2.  A “sealed service” is an entity which –

a.  “Persistently” maintains data Protected Health Information for or on behalf of Covered Entities and/or Business Associates,

b.  Which the entity does not have the ability to read, write, modify or communicate.

Neither a “conduit” nor a “sealed service” is considered a Business Associate. The key difference between the two is that a conduit is permitted to have some access to Protected Health Information, while a sealed service cannot have any. This suggests that a conduit may be able to manage its access limitations with administrative safeguards alone, while a sealed service must employ technical safeguards – probably encryption, as that (properly managed) would be the most effective.

Implications for ASPs and Cloud Services – and Maybe ISPs.

The limitations of the “conduit” and “sealed service” concepts may be a problem and something of a surprise to some cloud and application services providers. The problem is that Business Associate status and liability attach automatically when an entity obtains Protected Health Information for a purpose of a Covered Entity, even indirectly from or for a Business Associate. This means that even a services provider which doesn’t control what users upload and has no way of knowing what it is storing automatically becomes a Business Associate – with no Business Associate Contracts and without ever knowing it.

Consider for example Dropbox, which per Wikipedia is a free

. . . file hosting service operated by Dropbox, Inc., that offers cloud storage, file synchronization, and client software. Dropbox allows users to create a special folder on each of their computers, which Dropbox then synchronises so that it appears to be the same folder (with the same contents) regardless of which computer is used to view it. Files placed in this folder also are accessible through a website and mobile phone applications.

If, say, a physician practice (Covered Entity) or practice management services vendor (Business Associate) were to use a service like Dropbox as backup storage, that service would be automatically become a Business Associate, without notice, even if the practice or services vendor encrypted the Protected Health Information.

DHHS has already penalized a physician practice for storing unencrypted data in a cloud-based calendar service, and presumably under the new rules both the practice and the vendor could be penalized. Violations by the hosting service in this kind of scenario would include not only a wide range of compliance failures, including failure to have a Business Associate Contract.

It is also well worth noting that the “transient” versus “persistent” storage distinction which is supposed to differentiate Business Associate “storage” services from non-Business Associate “transmission” services doesn’t necessarily reflect all “transmission” models. Quite a few ISPs offer email services which include storage on the ISP’s servers for very long periods of time – “persistent” storage for periods determined by the user. While it may be true that Covered Entities (and Business Associates) shouldn’t transmit (and therefore potentially store) unencrypted email which includes Protected Health Information, if one does then under this analysis the ISP automatically becomes a Business Associate.

The sender more than likely violated the Security Rule in doing so, but under this analysis that is irrelevant:  The fact that the ISP is “maintaining” Protected Health Information in “persistent” storage is enough.

Conclusion.

My suspicion is that a major reason that the Omnibus Rule analysis came out as it did is that the conduit/data storage issue was not raised very strongly or clearly, especially in terms of analytical discussions. Then again, it wasn’t clear that OCR was considering a revised interpretation of the concept which would expressly exclude data storage, or what that might imply.

Of most concern is the problem of unexpected Business Associate status. This was raised in the comments on the proposed rulemaking, and not addressed by OCR. It may be that OCR assumed it was only a concern for data transmission services like AT&T (though the question was raised in other comments), and adequately dealt with by allowing for “random/infrequent” access to Protected Health Information. Whatever the reason, the risks associated with unanticipated, unmanaged (and possibly unknown) Business Associate status make this a difficult and unfair problem.

One way to handle this would be to allow for “sealed services” to qualify as such if they technically have “access” to Protected Health Information, but do not have notice that it is Protected Health Information and do so only for purposes of providing their service. Otherwise, I fail to see how services like Dropbox and ISPs which offer persistent storage which can be used to “maintain” Protected Health Information are protected from falling into unintentional Business Associate status without notice. Perhaps their terms of use could prohibit use of their services by Covered Entities or Business Associates, or for transactions or records which include Protected Health Information – but even if that were practical or desirable, under the current interpretation even storage of Protected Health Information contrary to a service’s terms of use probably wouldn’t prevent the service from being a Business Associate, and how would the service police it?

(NOTE: These problems are even worse and more pervasive if maintenance of encrypted PHI under “sealed service” conditions triggers Business Associate status. An entity might not even be able to know whether it was “maintaining PHI,” and would nonetheless be a Business Associate.)

I think this is a significant issue which should get some serious attention. It doesn’t seem to me that the interpretation which leads to this result is a necessary one, it has the potential for serious consequences for services which unexpectedly become Business Associates, it seems likely to prevent or drive off the market services which could be valuable and cost-effective, and it doesn’t actually seem to materially advance privacy or other interests. I hope OCR will revisit it, sooner rather than later given the Business Associate compliance timetable.

(Thanks to Gordon J. Apple and Clinton Mikel for their valuable insights into these issues. The opinions in this post and any errors are all mine, and not to be attributed to them, but they do really know their stuff.)