HIPAA Business Associate: That was then, this is now.
Whereas the HIPAA Privacy Rule (“PR”) deals with protected health information (“PHI”) in general, the HIPAA Security Rule (“SR”) deals with electronic PHI (ePHI), which is essentially a subset of what the Privacy Rule encompasses. In terms of actual regulatory text the Security Rule only spans approximately eight (8) pages, which is the good news. The bad news is the Security Rule is highly technical in nature. For all intents and purposes this rule is the codification of certain information technology standards and best practices.
Broadly speaking, the Security Rule requires that a Business Associate (“BA”) implement three types of safeguards: 1) administrative, 2) physical, and 3) technical. In addition, it imposes other organizational requirements and a need to document processes analogous to the Privacy Rule. That said, creating the necessary Security Rule documentation will likely prove significantly more “vexing” than its Privacy Rule counterpart, especially for a smaller Business Associate.
In short, small business associates, depending on their staff’s regulatory compliance and technical skills depth, will almost certainly need to hire HIT consultants if they want to “reasonably and appropriately” comply with the Security Rule. This article is a summary of a document that, together with the reference material cited, provides a roadmap for a Business Associate’s Security Rule implementation. However, it should be noted that this roadmap implies an iterative methodology for developing a “good Security Rule compliance story” and is not intended as a recommendation for a “one off big bang” project. This article focuses on providing an overview of relevant Business Associate compliance issues under HITECH.
Our guiding principle with respect to this rule is “implement the necessary safeguards.” We readily admit that this is much easier said than done, since the real challenge lies in defining “necessary.” As discussed below in the general rule, the Security Rule attempts to provide some “flexibility” in this regard (an apparent acknowledgment of the challenges faced by small providers, and now presumably under HITECH, small Business Associates as well), but as a practical matter does not otherwise significantly reduce the burden of implementation, in our opinion.
The Security Rule is contained in CFR sections §164.302 through §164.318. However, as discussed below a Business Associate, under HITECH, is only required to comply with a subset of the Security Rule, although, as it turns out, it is the most substantive subset.
Business Associate Security Rule Compliance
The HITECH Act identifies four specific sections of the Security Rule (i.e. those previously discussed in the Introduction) that a Business Associate is required to comply with under the statute. That means that failure to comply exposes the Business Associate to the same civil and criminal penalties (i.e. legal liability) that a Covered Entity has. In fact, the specific enumeration of sections is ambiguous and somewhat misleading.
These enumerated sections themselves reference other sections that are not part of the enumerated list (e.g .the General rule §164.306 as well as others). Therefore, we find this “regulatory hair splitting” completely useless, and therefore, recommend that a Business Associate simply comply with the Security Rule as written, since in any case it is being asked to comply with the most substantive sections.
Who is a Business Associate?
If you do business with health care providers then the obvious question is whether or not you are a business associates. The answer to that question is that "it depends on what you do on behalf of a Covered Entity, and specifically the kind of data that you interact with." In the general case, the definition of Business Associate means, with respect to a Covered Entity, a person who:
(i) On behalf of such covered entity or of an organized health care arrangement (as defined in §164.501 of this subchapter) in which the covered entity participates, but other than in the capacity of a member of the workforce of such covered entity or arrangement, performs, or assists in the performance of:
(A) A function or activity involving the use or disclosure of individually identifiable health information, including claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, billing, benefit management, practice management, and repricing; or
(B) Any other function or activity regulated by this subchapter; or
(ii) Provides, other than in the capacity of a member of the workforce of such covered entity, legal, actuarial, accounting, consulting, data aggregation (as defined in §164.501 of this subchapter), management, administrative, accreditation, or financial services to or for such covered entity, or to or for an organized health care arrangement in which the covered entity participates, where the provision of the service involves the disclosure of individually identifiable health information from such covered entity or arrangement, or from another business associate of such covered entity or arrangement, to the person.
In other words, a provider's business universe is literally chock-full of potential business associates. The key test however, is whether this "person" (or entity) requires the disclosure of "individually identifiable health information" in order to deliver their product or service to, or on behalf of, the Covered Entity?
What is Individually Identifiable Health Information ?
As a practical matter, what this term means is information that can be used to identify an individual patient. The definition in the regulations is as follows:
Individually Identifiable Health Information("IIHI")
is information that is a subset of health information, including demographic information collected from an individual, and:
(1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and
(2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and
(i) That identifies the individual; or
(ii) With respect to which there is a reasonable basis to believe the information can be used to identify the individual.
Therefore, the bottom line is that if you are in the business of providing a product or a service to a Covered Entity that requires you to "handle" IIHI then you are a Business Associate. This definition is quite broad, and as discussed above, includes many providers of professional services that heretofore probably did not think of themselves as business associates (e.g. attorneys and accountants).
What's a potential business associate's strategy for avoiding liability? That depends on the type of product or service you provide. If you provide professional services perhaps you can deliver the work without being exposed to IIHI. In that case. you simply don't meet the definition of a business associate. Obviously, this won't work for business associates that provide data services on behalf of a Covered Entity, including the majority of EHR vendors, whether they offer a hosted solution or not.
In short, under HITECH there are simply many more "cooks in the compliance kitchen." Why? Because from a public policy perspective that is the value that the legislators placed on this kind of health information. Essentially recognizing that newly empowered healthcare consumers simply will not tolerate a Laissez-faire posture with respect to PHI.
What is the difference between IIHI and Protected Health Information (PHI) ?
Not much. It is unclear why the regulators chose to split hairs and did not simply use one comprehensive definition, but that is what we got and we have to live with. PHI is essentially IIHI with a few exceptions. PHI is defined as follows:
Protected Health Information means individually identifiable health information:
(1) Except as provided in paragraph (2) of this definition, that is:
(i) Transmitted by electronic media;
(ii) Maintained in electronic media; or
(iii) Transmitted or maintained in any other form or medium.
(2) Protected health information excludes individually identifiable health information in:(i) Education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g;
(ii) Records described at 20 U.S.C. 1232g(a)(4)(B)(iv); and
(iii) Employment records held by a covered entity in its role as employer.
Unless an organization falls into one of the exception categories then IIHI equals PHI. Notice that the Business Associate definition above is written in terms of IIHI, and does not provide for exceptions. More often than not the general term PHI is used but as you now know they are not exactly one and the same.
It is easy to get lost in this regulatory "mumbo jumbo" and the best way to get clarity is to go back to the source. That is why we constantly link back. We want to encourage readers to become comfortable with the source.
Business Associate Compliance Touch Points?
There are a number of compliance touch points that a provider must consider when implementing an EHR. One of many significant touch points have to do with interoperability. Why is this an important compliance touch point? Because a business associate contract is almost certainly required with each one of the nodes depicted in the graphic below (except of course for other providers). In other words, the graphic below illustrates a very small subset of potential business associates. If your business provides one or more of these peripheral services then you are almost certainly a Business Associate by definition (i.e. difficult to see a how an organization could function in one of these roles and not handle IIHI).
But there are other compliance touch points that have more to do with a providers workflow and internal operations. There are additional Business Associates that play in this space. including many professional services providers (see the graphic below). For example your EHR systems integrator is almost certainly a Business Associate. It is hard to imagine a scenario where an integrator will not "handle" PHI as part of your implementation.
Here's a view of a generic front office for a small provider:
Business Associate Privacy Rule Compliance?
A Business Associate is not directly required by HITECH to comply with the HIPAA Privacy Rule, except of course as specified within the Security Rule (i.e. there are no “bright lines” between the two in certain areas). However, a Business Associate is required to comply with those sections of the Privacy Rule that are specified in the required contract with its respective Covered Entity.
Covered Entities are likely going to insist that a Business Associate comply with all appropriate substantive sections of the Privacy Rule that pertains to the type of service a Business Associate provides on behalf of the Covered Entity. In short, as a practical matter, Business Associate’s will be “on the hook” contractually regarding Privacy Rule compliance. HITECH Section 13404 strengthens the contractual arrangement between the parties by mandating, among other things, mutual reciprocal monitoring for a material breach of the contract.
The bottom line is that the regulatory environment for business associates has become much more complex.
Next Steps?
It is likely that this article raises as many questions as it answers. That's the nature of the beast. In order to deal with this level of complexity business associates need a common sense pragmatic approach. We believe we have provided a roadmap in:"The Security Rule Under HITECH: a Business Associate's Perspective (First Edition)."
Download a FREE copy of the HIPAA Survival Guide 4th Edition.