Five years out from the promulgation of the HITECH Act business associates are still struggling with what the Act requires of them under the modified HIPAA regulations. Although under the Omnibus Rule it should be clear that a business associate ("BA") must comply with the Privacy Rule, the Security Rule, and the Breach Notification Rule, it is the requirements of the Security Rule ("SR") that bedevils BAs the most.
Broadly speaking, the SR requires that a 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 ("PR"). That said, creating the necessary SR documentation will likely prove significantly more "vexing" than its PR counterpart, especially for a smaller BA.
In short, small BAs, 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 SR. This article provides a minimalist roadmap for a BA to launch an SR implementation. However, it should be noted that this roadmap implies an iterative methodology for developing a "good SR compliance story" over time and is therefore not intended as a recommendation for a "one off big bang" project.
The Act identifies four specific sections of the SR that a BA is required to comply with under the statute. That means that failure to comply exposes the BA to the same civil and criminal penalties that a covered entity ("CE") faces. In fact, the specific enumeration of sections is ambiguous and somewhat misleading. The enumerated sections in the SR 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 recommend that a BA simply comply with the SR as written, because in any case a BA is being asked to comply with the most substantive sections.
From the perspective of acquiring a "big picture" view of the SR the general rule is critical. It contains some guiding "flexibility" principles that are foundational to understanding how a "good story" may be developed, especially from the perspective of the small BA. However, we need to re-emphasize that "flexibility" does not mean (as per the rule), that a BA is free to ignore requirements, but rather that there may be some implementation "wiggle room" if properly documented.
The principal objectives of the SR, as it pertains to both a CE and a BA, are as follows (§160.306(a)):
- Ensure the confidentiality, integrity, and availability of all its ePHI.
- Protect against any reasonably anticipated threats or hazards of its ePHI.
- Protect against any reasonably anticipated uses or disclosures of ePHI not permitted or required under the Privacy Rule ("PR").
- Ensure its workforce complies with the SR.
The items enumerated above do not appear unreasonable or overly burdensome. However, the devil (as always) lies in the details of the specifications, some of which are absolutely mandatory while others are labeled "Addressable." The SR also contains a concept called the "Flexibility Approach;" what others refer to as the SR's guiding principle. In essence, the flexibility principle enumerates four factors that a BA should consider when deciding how to "reasonably and appropriately" implement the standards and implementation specifications.
The four SR Flexibility Factors are as follows:
- The size, complexity, and capabilities of the BA.
- The BA's technical infrastructure, hardware, and software security capabilities.
- The costs of security measures.
- The probability and criticality of potential risks to ePHI.
There appears to be some "wiggle room" in the SR, especially for small BAs. However, there is not as much as one might think when the SR is viewed in its entirety. The rule is made up of standards and their respective implementation specifications. A BA must comply with the standards; period, end of story. The implementation specifications are where the "wiggle room" lies (what there is of it). Specifications are either "Required" or "Addressable." Required specifications must be implemented. Addressable specifications must be assessed and implemented as specified if reasonable and appropriate to the BA. If not reasonable and appropriate, the reason it is not must be documented and an equivalent alternative measure must be implemented if the alternative is "reasonable and appropriate."
In short, all specifications must be dealt with in some way, shape, or form, by all BAs (large or small). The flexibility approach may ease the burden for small BAs, but no substantive requirements are eliminated. At a minimum, a small BA will need a compelling justification if an addressable specification is not implemented. A BA's implementation of the SR is likely to take six months to a year to complete, depending on the complexity of the BA's operational environment and the amount of resources and budget that are at the BA's disposal. At a minimum, we recommend that a BA do the following in order to demonstrate a good faith effort at compliance and perhaps avoid a finding of "willful neglect."
- Name a Security Officer.
- Name a Privacy Officer.
- Train your staff with Omnibus Rule Ready content.
- Perform a Risk Assessment.
This represents a minimalist approach, but if audited, it will at least allow a BA to argue that it has not ignored the requirements entirely.