Part 1 of this series introduced the HIPAA Security Rule ("SR" or "Rule") but did not get into its substantive requirements. This post will review the SR's Administrative Safeguards. Subsequent posts will cover the remaining safeguards and the major sections of the Rule as depicted in the graphic below. The "Risk Analysis & Risk Management" component is actually part of the Administrative Safeguards but is also reviewed separately due to its criticality.
The objective of this series is not to provide an exhaustive review of the SR, but rather to get those unfamiliar with its requirements grounded. One important thing to keep in mind is that the SR is a great example of the convergence between policy, law and technology.
These three fundamental underpinnings of the Rule must be examined holistically. If a provider or facility focuses on the HIT component standing alone (as some technology vendors may tend to encourage) then other non-technology aspects of the rule, which have policy/legal implications, may be missed entirely.
Introduction
The SR is made up of CFR Part 160 (Subpart A) and Part 164 (Subpart C). The principal objectives of the Rule, as it pertains to a covered entity are as follows (160.304(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 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 Rule also contains a concept called the "Flexibility Approach;" what others refer to as the Rule's guiding principle. In essence, the flexibility principle enumerates four factors that a covered entity ("CE") should consider when deciding how to "reasonably and appropriately" implement the standards and implementation specifications. The four factors are as follows:
- The size, complexity, and capabilities of the CE.
- The CE's technical infrastructure, hardware, and software security capabilities.
- The costs of security measures.
- The probability and criticality of potential risks to ePHI.
In short, there appears to be some "wiggle room" in the SR, especially for small providers. However, as will be discussed throughout this series, 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 CE must comply with the standards; period, end of story. The implementation specifications is 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 CE. 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 providers. The flexibility approach may ease the burden for small providers, but no substantive requirements are eliminated. At a minimum a small provider will need a compelling justification if an addressable specification is not implemented.
The Administrative Safeguards
The Administrative Safeguards ("AS") are contained in section 164.308. The AS contains eight (8) "technical" standards with eighteen corresponding implementation specifications, some of which are Required and others that are Addressable (164.308(a)) The AS also contains one (1) "business" standard (164.308(b)). The AS comprises over 50% of the SR.
164.308(a): The AS "Technical" Standards
The eight standards are as follows:
1. Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
2. Standard: Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the entity.
3. Standard: Workforce security. Implement policies and procedures to ensure that only appropriate members of the workforce have access to ePHI.
4. Standard: Information access management. Implement policies and procedures for authorized access to ePHI that are consistent with the applicable requirements of the PR.
5. Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).
6. Standard: Security incident procedures. Implement policies and procedures to address security incidents.
7. Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that could damage systems that contain ePHI.
8. Standard: Evaluation. Perform a periodic technical and non-technical evaluation to ensure that standards continue to be met in response to operational and environmental changes.
164.308(b): The"AS" Business Standard
Standard: Business associate contracts and other arrangements. A CE, in accordance with the general rule (§164.306), may permit a business associate ("BA") to create, receive, maintain, or transmit ePHI on the CE's behalf only if the CE obtains satisfactory assurances, in accordance with the Rule (164.314(a)) that the BA will appropriately safeguard the information. These assurances must be obtained by way of a written contract (or other arrangement) that meets the requirements of the Rule.
It should be noted and re-emphasized that a contract between the CE and BA must contain certain language in order to meet the requirements of the Rule (e.g. a "simple" contract that only states that the BA will protect the CE's ePHI is not sufficient). Furthermore, the HITECH Act now imposes stricter requirements on a BA and contains language that significantly increases the number BAs that a CE may need to interact with.Therefore, it is recommended that all existing BA contracts be reviewed, and where appropriate, re-drafted to conform to HITECH requirements.
Summary & Additional Resources
Process centric: Readers should note that the AS contains standards that are process centric. There is no commercial-off-the-shelf (COTS) technology solution that can be purchased that will satisfy these requirements.However, there are templates and other reusable collateral that can help "jump start" the effort.We chose to use the words "Technical" and "Business" to differentiate the types of processes that must be implemented and documented.
Regulators will likely insist on seeing demonstrable evidence that a provider or facility has "attacked" these standards with a degree of rigor. Demonstrable evidence means significantly more than just having the necessary documentation available, it requires proof that the required processes have been implemented and are being used to achieve the desired effect. In other words, do not confuse "documented" with "implemented." These are two distinct concepts and both are required.
Standard: Security management process. While all the AS standards must be met, the first is arguably the most important and will be further explored in the "Risk Analysis & Risk Management" part of this series. This standard has four Required implementation specifications: 1) Risk analysis, 2) Risk management, 3) Sanction policy, and 4) Information system activity review.
The first two of these specifications are quite broad in scope. An in depth review of this standard (and its corresponding specifications) will be provided as an example of the process by which the requirements of the other AS standards can be met. It will be difficult (to say the lest) to meet HHS' meaningful use definition if a provider or facility has: a) not addressed the AS standards at a minimum; and b) does not have a plan in place for meeting all of the SR requirements, and it should go without saying, the requirements of the PR as well.
Electronic vs. oral and paper: It is important to note that the Privacy Rule applies to all forms of patients’ protected health information, whether electronic, written, or oral. In contrast, the Security Rule covers only protected health information that is in electronic form. This includes ePHI that is created, received, maintained or transmitted. For example, ePHI may be transmitted over the Internet, stored on a computer, a CD, a disk, magnetic tape, or other related means. The Security Rule does not cover PHI that is transmitted or stored on paper or provided orally.
Additional Resources
If readers are looking for additional regulatory information regarding HIPAA's Security Rule then the HHS Security Standard Portal is the place to start. Readers should take special note of the HIPAA Security Educational Paper Series. The Educational Series contains a number of PDF documents that correspond to major sections of the Security Rule.
Part 3 of this series can be found here.
Looking for a best of breed HIPAA Compliance Tracking System?
To stay current on the HITECH Act and its quickly changing regulatory scheme visit the HITECH Survival Guide website and/or sign up for our free monthly compliance newsletter. Also, check out our FREE EHR Checklist.
If you need tools that will help with your compliance initiatives then check out the HSG Store. Do you need an Internet Lawyer with HITECH / HIPAA experience?
