THE SECURITY RULE
Whereas the Privacy Rule deals with Protected Health Information (PHI) in general, the Security Rule (SR) deals with electronic Protected Health Information (ePHI), which is essentially a subset of what the Privacy Rule encompasses. In terms of actual regulatory text the Security Rule only spans approximately 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 implementation of 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 small providers. Health information technology (HIT) resources should be available for these types of projects.
Maximize the HITECH Act - Download this free EHR Software Checklist !!!
In short, small providers will almost certainly need to hire HIT consultants if they want to "reasonably and appropriately" comply with the Security Rule. Given this reality, we simply present the general rule and the standards captured in the enumerated safeguards, with brief commentary that hopefully explains in lay terms what a particular standard means. A given standard usually has implementation specifications associated with it. We have opted not to discuss the Security Rule specifications (only the standards) since it is our belief that any attempt at paraphrasing the specifications would only add to the confusion.
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 acknowledgement of the challenges faced by small providers), but as a practical matter does not otherwise significantly reduce the burden of implementation, in our opinion.
The provider compliance date for the security standards was April 20, 2005 (§164.318). The Security Rule is contained in sections §164.302 through §164.318.
§ 164.302 Applicability
A Covered Entity must comply with the standards and implementation specifications contained herein.
§ 164.304 Definitions
Introductory Comment: The definitions below are a paraphrased subset of all the definitions contained in the Security Rule. The omitted definitions, by and large, are technical terms that are useful for interpreting the implementation specifications. Since we have omitted any discussion of the specifications there is no need to define the technical terms related to them.
Access
Access means the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource.
Administrative safeguards
Administrative safeguards are administrative actions, policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the Covered Entity's workforce in relation to the protection of that information.
Confidentiality
Confidentiality means the property that data or information is not made available or disclosed to unauthorized persons or processes.
Physical safeguards
Physical safeguards are physical measures, policies, and procedures to protect a Covered Entity's electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.
Technical safeguards
Technical safeguards mean technology and the policy and procedures for its use that protect electronic health information and control access to it.
Check Out the Free Online Data Backup Checklist.