The HIPAA Security Rule requires physicians to protect patients' electronically stored, protected health information (known as “ePHI”) by using appropriate administrative, physical and technical safeguards to ensure the confidentiality, integrity and security of this information. Essentially, the Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and nontechnical safeguards that covered entities must implement to secure ePHI. All covered entities must assess their security risks, even those entities who utilize certified electronic health record (EHR) technology. Those entities must put in place administrative, physical and technical safeguards to maintain compliance with the Security Rule and document every security compliance measure. HIPAA defines administrative safeguards as, “Administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.” (45 C.F.R. § 164.304). These are, like the definition says, policies and procedures that set out what the covered entity does to protect its PHI. Rather than actual physical safeguards or technical requirements, these requirements cover training and procedures for employees of the entity, whether or not they have direct access to PHI. Physical safeguards involve access both to the physical structures of a covered entity and its electronic equipment (45 CFR §164.310). ePHI and the computer systems in which it resides must be protected from unauthorized access, in accordance with defined policies and procedures. Some of these requirements can be accomplished by using electronic security systems, but physicians should not rely on use of certified electronic health records technology (CEHRT) to satisfy their Security Rule compliance obligations. Technical safeguards encompass the technology, as well and the policies and procedures for its use, that protect ePHI and control access to it. They are often the most difficult regulations to comprehend and implement (45 CFR §164.312). The Security Rule incorporates the concepts of scalability, flexibility and generalization. In other words, the regulations do not expect the same security precautions from small or rural providers as are demanded of large covered entities with significant resources. Security is recognized as an evolving target, and so HIPAA’s security requirements are not linked to specific technologies or products. HHS has stated it is focused more on what needs to be done and less on how it should be accomplished. The security regulations consist of a 3-tiered system of requirements. First, there is a series of standards, legal requirements that all entities are expected to meet. Second, there may be implementation specifications that provide detailed instructions and steps to take in order to be in compliance with the standard. In an effort to make the Security Rule more flexible and applicable to covered entities of all sizes, some implementation specifications are required, while others are only addressable. Required implementation specifications must be implemented by all covered entities. Addressable implementation specifications require a covered entity to assess whether the specification is a reasonable and appropriate safeguard in the entity’s environment. If the specification is reasonable and appropriate, the covered entity must implement the specification. If a covered entity determines that an addressable implementation specification is not reasonable and appropriate, it must document its assessment and basis for its decision and implement an alternative mechanism to meet the standard addressed by the implementation specification. To comply with the Security Rule’s implementation specifications, covered entities are required to conduct a risk assessment to determine the threats or hazards to the security of ePHI and implement measures to protect against these threats and such uses and disclosures of information that are not permitted by the Privacy Rule. A risk assessment should be tailored to the covered entity’s circumstances and environment, including the following:
Note, however, that HHS has made it clear that cost alone is not a sufficient basis for refusing to adopt a standard or an addressable implementation specification. Fortunately, the rules are not prescriptive and a number of tactics can achieve compliance. To assist physicians with the risk-assessment process, the U.S. Department of Health & Human Services (HHS) Office of Civil Rights has developed a downloadable "Security risk assessment tool." Behind every security compliance measure is a documentation requirement. Practically every facet of HIPAA compliance requires that policies and procedures be created and implemented. These documents must be retained for at least six years (and state requirements may mandate longer retention periods). Policies may be changed at any time, so long as the accompanying documentation is also updated. Regulations require periodic review of policies and responses to changes in the ePHI environment. This resource is provided for informational and reference purposes only and should not be construed as the legal advice of the American Medical Association. Specific legal questions regarding this information should be addressed by one's own counsel.
Whereas the HIPAA Privacy Rule deals with Protected Health Information (PHI) in general, the HIPAA Security Rule (SR) deals with electronic Protected Health Information (ePHI), which is essentially a subset of what the HIPAA Privacy Rule encompasses. In terms of actual regulatory text the HIPAA Security Rule only spans approximately 8 pages, which is the good news. The bad news is the HIPAA 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 HIPAA 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 HIPAA Privacy Rule. That said, creating the necessary HIPAA 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. Carlos Leyva explains Attacking the HIPAA Security Rule!
Get our FREE HIPAA Breach Notification Training! In short, small providers will almost certainly need to hire HIT consultants if they want to "reasonably and appropriately" comply with the HIPAA 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 HIPAA 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 HIPAA 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 HIPAA Security Rule is contained in sections §164.302 through §164.318. § 164.302 ApplicabilityA Covered Entity must comply with the standards and implementation specifications contained herein. § 164.304 DefinitionsIntroductory Comment: The definitions below are a paraphrased subset of all the definitions contained in the HIPAA 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. Questions about HIPAA Compliance in this post HITECH/Omnibus Final Rule world? Make sure you are Omnibus Rule Compliant: HIPAA Privacy Checklist. © 2009-2022 3Lions Publishing, Inc. |
What is HIPAA administrative safeguards?
Pos Terkait
Copyright © 2024 membukakan Inc.
