Module 3: HIPAA Security Fundamentals

David Holtzman
Length: 50:36 | Format: Video with PowerPoint
Related Content: Module 3 HIPAA Security Fundamentals.pdf

Loading the player ...

Good Afternoon. I am your post-lunch speaker. I am so happy to be here. My name is David Holtzman. I am the Team Leader for enforcement of the Security Rule with the Health Information Privacy Team. I've been with OCR for about six and a half years. Still love coming to work everyday. Prior to joining OCR, I was the Privacy and Security Officer for Kaiser Permanente in the Mid-Atlantic area. And in that role, I implemented the privacy and security rules for Kaiser and got a lot of good experience and learning how to translate policy into practice. So, giving a little bit of background...(backfeed)... Okay, so, how many of us stayed in a hotel last night? Hmm? How many of us have used the computer in the business area of the hotel? You know the little business common area that they provide the public computer. If you're ashamed to say, you don't have to raise your hand. Well, you know, I am a professional investigator. I investigate for health information privacy and security. And every once in a while, while I am staying in a hotel, I like to go up to the computer to see what others have left on there. I rarely come away disappointed from finding some information, some health information that has been downloaded to the computer by a user and left there for others to see. Countless others. My experience in doing the State Attorney General Training, the first one in Dallas was no different and it was a fruitful exercise. So this is, this is really an entree into the larger privacy and security issues and how you require a culture of compliance in an organization to be careful to be to have awareness as to how to ensure the integrity of the health information that you are entrusted into. So with that little entree, we're going to talk about the Security Rule. This Module discusses the three objectives of health information security-confidentiality, integrity and availability—and the importance of ensuring that security objectives are met to protect the privacy of an individual's health information. This module will also introduces the Health Insurance Portability and Accountability Act, HIPAA's unique security-related concepts—including "scalable," "flexible," and "reasonable and appropriate"—as they relate to implementing safeguards to protect electronic protected health information, or often times we just call it e-PHI. Finally, the module's going to describe the elements of the HIPAA Security Rule, including security standards and implementation specifications with an emphasis on the importance of risk analysis and overall risk management process and discuss the inter-relationship between security and privacy. And, the module concludes with an activity where you will be able to be given a chance to identify a security rule violations from the State of Connecticut Case involving HealthNet. So, after completing this module you'll be able to discuss fundamental requirements of the HIPAA Security Rule, describe the HIPAA Security Rule standards and implementation specifications, and explain how the HIPAA Security Rule objectives and key concepts relate to building and evaluating a Security Rule compliance program, and hopefully develop some investigatory questions to apply to the cases that you'll come into contact with. So, in this first lesson or objective, are to understand confidentiality, integrity and availability. And we introduce the key HIPPA security-related concepts including "scalable" and "flexible", and "reasonable and “appropriate", as they relate to implementing safeguards to protect e-PHI. Our goal from this lesson is to help you identify fundamental HIPAA Security Rule concepts for you to use in case investigations and to analyze HIPAA Security Rule requirements in implications for enforcement. So, what is the HIPAA Security Rule? Well, simply, the HIPPA Act of 1996 required the Secretary of HHS to promulgate regulations protecting the privacy and security of certain health information. These regulations commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule, as you know. The Security Rule, or known as the Security Standards for the Protection of Electronic Protected Health Information, established a national floor, a set of standards for safeguarding e-PHI that is created, received, stored, or transmitted in electronic form by a HIPAA-covered entity. The Security Rule addresses addresses the administrative, physical, and technical safeguards that covered entities must put in place to secure individuals' e-PHI. And we're going to discuss these safeguards in greater detail later in this module. Although the Security Rule only applies to protected health information in electronic form, the Privacy Rule requires covered entities to reasonably safeguard PHI in all forms—oral, paper, and electronic. An example, a paper record containing PHI that is sent through a fax machine in which the fax machine receives the transmission and produces a paper facsimile of the original, but does not store an electronic copy, is generally not considered e-PHI. This also goes, this same analysis goes for the transmission of voice over a landline copper telephone or through a cellular telephone. So, what are our objectives in learning the HIPAA Security Rule? The Security Rule requires each covered entity to protect against reasonably anticipated threats and hazards to the confidentiality, integrity or availability of e-PHI, to protect against reasonably anticipated impermissible uses or disclosures, and to ensure compliance by its workforce with the policies and procedures that the covered entity puts into place. Under the Security Rule, covered entities are required to implement administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability, of e-PHI that they create, receive, store, or transmit. Confidentiality means that e-PHI is not made available or disclosed to unauthorized persons or processes. The confidentiality of health information is threatened not only by the risk of improper access to stored information, but also by the risk of interception during electronic transmission of the information. The Security Rule's confidentiality requirements support the Privacy Rule's prohibitions against improper uses and disclosures of PHI. Integrity means ensuring that e-PHI has not been altered or destroyed in an unauthorized manner. The failure to assure data integrity could lead to medical errors because of inappropriate treatment or a failure to provide needed treatment. Availability means that ePHI is accessible and usable when the information is needed. The loss of availability could delay treatment, or lead to inappropriate treatment in the absence of adequate information. You'll notice that we represent these three foundational principles, these pillars of information security as a triangle. And like any triangle, when you take away one leg, you weaken all the other legs. So confidentiality, integrity and availability are the foundations of information security. The majority of Security Rule violations investigated by HHS through the Office for Civil Rights result from a covered entity not having adequate policies and procedures in place to safeguard e-PHI contained in its information systems, or having safeguards to protect e-PHI stored on portable devices and to safeguard them from loss or theft. The HIPAA Security Rule recognizes that covered entities range from the smallest provider, or as Iliana puts it, “a one doc shop”, to the largest, multi-state health plan. Therefore, the Security Rule is structured to be “scalable” and “flexible” to allow covered entities to implement HIPAA security standards in a manner that is appropriate for the size and complexity of their organization. This means that the Security Rule intentionally allows covered entities to adopt security policies, procedures, and technologies for meeting each of the Security Rule's requirements that are appropriate to their unique environments. Therefore, policies and procedures, and technologies covered entities adopt can be tailored based on their size, complexity and capability and their technical, hardware and software infrastructure. The policies, procedures, and technologies a covered entity adopts can be tailored based on the costs of security measures relative to the risks and we are going to discuss in detail, risk and related considerations later in the module, the likelihood and possible impact of potential risks to the confidentiality, integrity or availability of electronic protected health information and security measures will be reviewed and modified to continue protecting e-PHI in a changing environment. An example: An organization deploys new technology such as a large physician practice establishing WiFi access so that staff and providers can use i-Pads to access the health records of patients being seen for treatment. The Security Rule requires covered entities to assess the threats and vulnerabilities in their environments and implement standards and implementation specifications to safeguard e-PHI. These standards ensure the confidentiality, integrity and availability of e-PHI against reasonably anticipated threats or vulnerabilities that are identified through the covered entity's analysis of risks. The Security Rule requires covered entities to implement safeguards that are "reasonable and appropriate" based on the risk analysis. The Security Rule does not define risks, vulnerabilities and threats. The definitions included in the Security Rule draw on common industry usage. In explaining key security concepts, many organizations use terminology defined by the National Institute of Standards and Technology, or the acronym NIST. NIST is a federal agency and NIST publications are freely available in the public domain. Although only federal agencies are required to follow guidelines set by NIST, the guidelines represent the industry standard for good business practices with respect to standards for securing e-PHI. While NIST guidance is not required to be adopted by private sector entities, NIST publications provide definitions that are broadly understood and accepted throughout the information technology industry. So, in looking at the definitions, let's look first at vulnerability. And when we, and as I refer to the definitions, these definitions can be found in NIST Special Publication 800-30 and this we have a link to this off our website, at the OCR website. So vulnerability is defined by NIST as a flaw or weakness in a system security procedure, design, implementation, or internal controls that could be exercised, that is accidentally triggered or intentionally exploited and result in a security incident or a violation of the system's security policy. Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as an inappropriate use or disclosure of e-PHI. Vulnerabilities may be grouped into two general categories, technical and non-technical. Non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines, while technical vulnerabilities may include: holes, flaws or weaknesses in the development of information systems; or incorrectly implemented or configuring information systems. A threat as defined by NIST, is the potential for a person or a thing to exercise, again, accidentally trigger or intentionally exploit a specific vulnerability. Threats that could impact the confidentiality, integrity or availability of e-PHI include natural threats, such as floods, earthquakes, tornadoes, and landslides; human threats, such as intentional network and computer-based attacks, malicious software uploads, unintentional data entry or deletion, or inaccurate data entry resulting in unauthorized access to e-PHI. And then there are environmental threats, such as power failures, chemical and liquid leakage or pollution through an oil well blowout. And finally, risk. An adapted definition of risk is the impact considering the probability that a particular threat will be exercised either accidentally triggered or intentionally exploited to a particular vulnerability and the resulting impact if this should this occur and risks arise from legal liability or mission loss due to an unauthorized disclosure, modification, or destruction of information, unintentional errors and omissions, IT disruptions due to natural or manmade disasters or failure to exercise due care and diligence in the implementation and operation of the IT system. Thus, risk can be understood as a function of the likelihood of a given threat triggering or exploiting a particular vulnerability, and the resulting impact on the organization. This means that risk is not a single factor or event, but rather is a combination of factors or events. In other words, threats and vulnerabilities that, if they occur, may have an adverse impact on the organization. So, let's recap our first area. The Security Rule requires covered entities to implement standards to ensure the confidentiality, integrity and availability of their information systems and the e-PHI they create, receive, store, or transmit, and to prevent, detect, contain, and correct security violations. The HIPAA Security Rule is designed to be “scalable” to fit covered entities of all size. It also allows “flexibility” so that covered entities and their business associates can apply security measures appropriate for their environments. It also allows covered entities and their business associates to implement safeguards that are “reasonable and appropriate” based on their analysis of risk and risk analysis is a topic we're going to discuss later in the Module. So, Lesson Two. This lesson describes key elements of the HIPAA Security Rule, including security standards and implementation specifications and the inter-relationship between privacy and security. Our goal is for you to be able to: differentiate between standards and implementation specifications, and to describe the three types of the HIPAA Security Rule safeguards covered entities are required to implement to protect e-PHI, and to explain the importance of ensuring that a covered entity has engaged in a risk analysis as a part of a holistic risk management process to identify vulnerabilities and the steps taken to mitigate those risks when investigating compliance with the Security Rule, and we're going to discuss the inter-relationship of privacy and security. Many Security Rule standards contain implementation specifications. Implementation specification is a more detailed description, perhaps even a procedure of the method or approach required entities should use to implement security safeguards to meet a particular standard. Under the HIPAA Security Rule, all standards are required, while the implementation specifications for the security standards are considered to be either “required” or “addressable.” A “required” implementation specification must be implemented by all covered entities. “Addressable” implementation specifications are NOT optional; however, covered entities are permitted to determine whether each addressable implementation specification is “reasonable and appropriate” for their individual environments. If it is not reasonable and appropriate, the covered entity may substitute a reasonable and appropriate alternative security measure, but they must maintain documentation explaining their rationale for accepting the alternative. An example, as an example, one of the technical safeguards, the Access Control Standards, has four implementation specifications. Two are required and two are addressable. In this example, the covered entity is required to implement the specifications for assigning a unique name or number for each user and establishing emergency access procedures. However, the implementation specifications to automatically log off users after a period of inactivity and to implement a mechanism for encryption and decryption are “addressable.” This means that the covered entity must implement those measures if they are reasonable and appropriate to the size and complexity of the organization and based on the environment in which they operate. If the covered entity determines that an “addressable” implementation specification is NOT “reasonable and appropriate”, the Security Rule allows the covered entity to implement an alternative safeguard, as long as it is equivalent in protecting e-PHI based on the organization's analysis of the risk and achieves the purpose of the standard. The covered entity must document why the safeguard was determined to not be “reasonable and appropriate” and how the alternate mitigation in safeguarding e-PHI is equivalent. If no alternative would be “reasonable and appropriate”, in other words, the covered entity wants to accept the risk of that vulnerability, the covered entity must also document how this determination was made. An example: An operating nurse doesn't want to be required to re-login to an operating room computer every time it reaches the entity's established maximum period of inactivity, resulting in a screensaver login screen. We often face this in our office environments. After fifteen minutes of inactivity, our computers screens will log-off and we are required to log back in. To mitigate this requirement, the covered entity could issue the nurse an access card for the duration of the surgery, thus allowing access to the computer. At the end of the surgery the access card would be returned. Upon return of the access card, the covered entity has assured that the confidentiality, integrity and availability of the health information that it stores on its information system is assured. Administrative safeguards are a set of policies and procedures that a covered entity must have in place to protect the e-PHI that it creates, receives, maintains, or transmits. The standards and implementation for specifications for administrative safeguards include risk analysis and risk management, access management, workforce training, and evaluation of security measures. I would like you to bear in mind as we move through these three sets of safeguards, administrative, physical and technical, that the administrative safeguards are more likely to be inter-woven and a part of all of the other safeguard areas that we're going to be reviewing. So, there is a larger copy of this table located on Page 45 of your Appendix for your later review. Oh, I am sorry…I'm supposed to…The Security Management Process is probably the foundation of many of the activities we're going to be talking about in our presentation today. Another area that's also important is Security Awareness Training. This is similar to the provision in the Privacy Rule, where a covered entity must provide training on the provisions of their policies and procedures implemented to comply with the Security Rule requirements and the evaluation requirement is part of the security management process. Evaluation means that upon a change in operational or environmental circumstances, a covered entity should go back through and perform a risk analysis, in other words, have a lifecycle of risk analysis and we'll explore that in a little bit. So, an important, required implementation specification that may be especially relevant to the work that you all are going to be doing in enforcing the Security Rule is the requirement that an organization conduct a risk analysis. Notice how we've put our little three-legged triangle up...well, all triangles are three-legged. How we've put our triangle up here showing the principles of confidentiality, integrity and availability. So, a risk analysis is fundamental to understanding how to preserve these foundational principles. The Security Management Process standard requires covered entities to implement policies and procedures to prevent, detect, contain, and correct security violations. As a part of their security management process, covered entities are required to conduct a risk analysis. That is, they must perform an accurate and thorough analysis of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the e-PHI they create, receive, maintain or transmit. And this activity is so fundamental in that our investigation of Security Rule complaints and in compliance reviews, this is one of the first things we ask for and if we do not receive it, it is a good first step clue that the covered entity is not in compliance. So conducting a risk analysis is that critical first step in identifying and implementing safeguards that comply with and carry out the standards of the implementation specifications of the Security Rule. The scope of the risk analysis includes PHI in all forms of electronic media, such as hard drives, the good old floppy disk, CDs, DVDs, Smart cards, Smartphones or other storage devices, personal digital assistants, transmission media, or portable electronic media, like a thumb drive. Electronic media includes a single workstation as well as complex networks connected between multiple locations. Thus, an organization's risk analysis should take into account all of its e-PHI, regardless of the particular electronic medium in which it is created, received, stored or transmitted, or the source or location of its e-PHI. A comprehensive risk analysis will provide covered entities with a detailed understanding of the risks associated with the e-PHI they create, receive, store or transmit, and will assist them in determining what protections are reasonable and appropriate for their organization. Risk analysis is a necessary tool for reaching compliance with other HIPAA security standards and the implementation specifications. As the outcome of a risk analysis will provide covered entities with the information needed to assess whether an “addressable” implementation specification is a reasonable and appropriate choice for that organization. Although the Security Rule does not specify how often a covered entity must complete a risk analysis, doing so on a regular basis will aid in anticipating potential risks in a changing environment. And I want to point out that the evaluation standard encompasses those changing environments. The covered entity should regularly review records and system logs to track access to e-PHI, identify new threats and vulnerabilities, and detect security incidents. As I said, a covered entity's failure to conduct a risk analysis could result in HIPAA violations that would be subject to our mutual investigation. Therefore, this should be of interest to SAG when a Security Rule complaint is filed and the first question is to determine whether or not a covered entity has conducted risk analysis and implemented the safeguard that address the identified risks. This slide contains examples of questions that covered entities should consider as part of a risk analysis. The answer to these questions can help provide key information for State Attorney Generals during an investigation into a potential HIPAA security violation. These sample questions are not prescriptive and merely identify issues a covered entity may wish to consider in implementing its Security Rule compliance program. So, once the covered entity has completed the risk analysis like we've done here. It's gotta take action to address those risks. Implementing safeguards that minimally address each of the standards and implementation specifications often will not be enough to satisfy this requirement. So, recall, in our activity, the items where the risk level was higher medium, and recall that a covered entity is required to take any additional risk and appropriate steps to reasonably anticipate such risks and guard against them. So, in looking on the screen and then looking at this simple risk analysis, hopefully we can come away with what's very important to identify what could happen, how likely it is to happen and then what steps can we take to do away with the risk, or to mitigate the risk, or in some cases we have to accept that there's not much we can do, or it's low enough that we're going to accept the risk. And the last point that I want to make in risk analysis is that whatever mitigation and steps we take, the most important thing we can do after we've taken our action is to ensure compliance with the Privacy and the Security Rule provisions by the workforce. In other words, train our workforce, evaluate our workforce, and then apply sanctions to the workforce if and when they don't follow the rules. And when we go out and evaluate how covered entities are in compliance with the Security Rule, we evaluate the covered entity as to how well they accomplished each of those steps. Let's take a moment and talk about physical safeguards. Physical safeguards are the policies and procedures covered entities are required to put in place to ensure the physical protection of electronic information systems from natural threats, environmental threats, or unauthorized physical intrusion. These can include providing protection against fires, floods, or theft of equipment. And as we have seen in our experience, in measuring and evaluating large information breaches, large information breaches are two-thirds of them…are loss or theft of data is responsible for two-thirds of these…incidents. So, the physical safeguards are located on Page 46 of your Appendix. And just to briefly go through them, facility access controls are kind of the…the measures that you would take to control access to a facility-locks, doors, alarms, video monitoring and notice how these things are addressable. They're generally more reasonable and appropriate to the larger, more complex organization, where workstation use, who can use the computer terminal…that is a required implementation specification. Workstation security. How do we protect the workstation from unauthorized use? And device and media controls. How many of us have heard the story of buying a computer on E-bay, cranking it up for that first time, and looking at the medical records or the financial records of the customers or the patients of the organization that sold the computer. Under the Security Rule, a covered entity is required to have policies and procedures in place to prevent the data that's stored on a device, whether it's a portable device or media like a thumb drive, or a portable hard drive, that that e-PHI, the confidentiality, integrity and availability of that must be safeguarded from unauthorized use or disclosure. Technical safeguards mean the technology and the policies and procedures for the use that covered entities must put in place for e-PHI from unauthorized access and disclosure. Technical safeguards can include user log-ins and passwords established with appropriate access level controls and audit logs to report as to who gained access, where they went within the information system, and what they did with the information. A larger copy of this table is also available on Page 46. And, I'd like to call to your attention, Audit Controls. Audit Controls are applications or software that permits a covered entity to get reports on who has access to information or who has attempted to access information, whether it's a system as a whole or the specific applications that store or create Electronic Protected Health Information. In another important required standard, well, all the standards are required and the implementation specification is person or entity authentication, so that even if you've given a user credential and authorized user name or password, there has to be some process in place some automated process, software application that authenticates that is the user who I gave the user credential to. In other words, the password matches up with the user name. So, in line with the Security Rule's fundamental concepts of scalability and flexibility, there are no specific requirements for what types of technology must be implemented to demonstrate compliance with the Security Rule's technical safeguards. This policy is sometimes described as being “technology neutral”. However, entities must implement technologies that achieve the standards set out in the Security Rule. So, you might want to determine whether a covered entity has addressed the following standards when implementing technical safeguards: Do they have access controls? A covered entity must implement technical policies and procedures that allow only the authorized persons to access e-PHI. Audit controls? A covered entity, as we said, must implement hardware, software, or procedural mechanism to record and examine access or attempted access or other activity in information systems that contain or use e-PHI. Integrity Controls. A covered entity must implement policies and procedures to ensure that the e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed. Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network. While we have discussed the administrative, physical, and technical safeguards individually it should be noted that the safeguards really are interdependent of each other. For example, a national health insurance company sent explanation of benefits, or EOB, by mail to the adult stepson of a plan member. OCR's investigation determined that the health plan had recently updated the operating software in its information systems. A flaw in the programming code corrupted information in the account records of individual accounts, causing them to be changed and putting the PHI of two thousand families at risk of disclosure in violation of the Rule. Among other corrective actions to resolve the specific issues in the case, OCR required the insurer to correct the flaw in its computer system, implement administrative controls to manage software changes to its information systems, and correct all corrupted patient information.   And this, I think this is the last. Yes, this is the last slide before we take a break. Let's quickly go over encryption. Encryption is the method of converting an original regular text, such as you put into an e-mail or electronic document, into unreadable text that may be decrypted into readable text by an authorized user. The goal of encryption is to protect e-PHI from being accessed and viewed by unauthorized users. The Security Rule contains two implementation specifications related to encryption. While both of these are addressable, adopting encryption technologies will be reasonable and appropriate for many covered entities based on their analysis of risks. This is especially true when a covered entity that stores information on a hard drive of a device that can fit under somebody's arm, whether it be a laptop or some other portable device, a thumb drive or a portable storage device.If the risk analysis indicates significant risk of unauthorized access, either when Electronic Protected Health Information is at rest in the covered entity's information systems or during the transmission of e-PHI, then it is likely that the covered entity will need to implement an encryption solution. It should be noted that while encryption is a technical safeguard, it has ties to administrative and physical safeguards as well. For example, laptops and other media like portable flash drives containing unencrypted e-PHI removed from the premises by employees of a large health system in the normal course of their work. For example, to work at home or at another facility. The employees subsequently left the portable devices unattended and unsecured. They were in the back of their car. Some were left in automobiles while others were in offsite work locations. Sometimes they were left on planes, trains. The media and laptops were subsequently lost or stolen, compromising the PHI of over 386,000 patients. Among the corrective actions that the covered entity was required to take, they had to revise their policies and procedures regarding technical safeguards for the information stored on portable devices, such as encryption, as well as physical controls governing off-site transport and storage of electronic media containing patient information. In other words, they couldn't be left in the backseat of the car. In addition, the healthcare provider was required to implement training for its workforce members, which is an administrative safeguard, as well as training on overall privacy and security compliance in the new policies and procedures it was created. Okay, so we spent some time talking about risk analysis, a risk management process, the standards of the Security Rule and implementation specifications, and whether implementation specifications were “required” or “addressable”, and how to determine what would be “reasonable” and “appropriate” implementation of an “addressable” implementation specification. I'm so proud I can say that at three o'clock in the afternoon. And then we went over the safeguards areas, the administrative safeguards, the physical safeguards, and the technical safeguards. So, let's take a moment and talk about the inter-relationship between the Privacy Rule and the Security Rule. The Security Rule can be thought of as a subset of the Privacy Rule. In other words, if you were to take a Venn diagram, two circles. Have one big circle and it would be the Privacy Rule, and have another circle…you've often seen this…think like the Olympic Rings. That the Security Rule is wholly within…well, perhaps the Olympic Rings isn't a good enough…The Security Rule is wholly within the Privacy Rule. The Privacy Rule assures the confidentiality and the authorized uses and disclosures of all Protected Health Information in any form. And the Security Rule, as we have discussed, provides for safeguards for the confidentiality and integrity and availability of Electronic Protected Health Information, or a subset of that information as safeguarded by the Privacy Rule. So, in the course of an investigation, certain events or conditions may exist that indicate a violation of both rules. So, in fact, as we've discussed, the Privacy Rule requires covered entities to provide appropriate administrative, physical and technical for PHI. The Privacy Rule describes permissible uses and disclosures and requires that covered entities take steps to prevent other uses and disclosures. The Security Rule provides specific methods by which the protections required by the Privacy Rule can be achieved. For example, the unique password requirements of the Security Rule help to ensure that the minimum necessary provisions of the Privacy Rule are met. Note that in the course of an investigation, certain events or conditions may exist that could indicate a violation of both Rules. In fact, the Privacy Rule requires covered entities to provide appropriate administrative, physical, and technical safeguards for PHI, which is parallel to the requirements of the Security Rule. This requirement, sometimes known informally as the “mini-Security Rule”, is significant because the Privacy Rule in effect requires security for PHI, even for non-electronic PHI, which is not regulated under the Security Rule. So, for example, if a person gains access to an information system with the intention of viewing the medical records of co-workers, not an uncommon occurrence, this may indicate a violation of both rules. It may violate the HIPAA Privacy Rule if the person who gained access was not authorized to view the medical records, since this would constitute an impermissible use. It may violate the Privacy Rule's safeguards standard, and the HIPAA Security Rule if the unauthorized access resulted from a lack of adequate security safeguards. Note also that also both the Privacy and Security Rules require covered entities to conduct similar activities. From a compliance perspective, many covered entities find it convenient to align these processes for maximum efficiency. Some examples would be having training and awareness training for employees and other workforce members into the requirements and policies and procedures of the Privacy and Security Rule. We've talked about how one official has to be given a responsibility for compliance with the Privacy Rule, although another individual can be given responsibility for the Security Rule. In addition, there has to be documentation for policies and procedures for both compliance with the Privacy and Security Rule. So, from a compliance perspective, they may unify that process, but from an enforcement perspective, it may be efficient to understand, to investigate with the understanding that many practices implicate both rules at the same time. So, let's take a moment and talk about questions that we would ask in investigation. So, some questions that we'd want to ask or to determine whether or not a specific incident involved a violation of the HIPAA Security Rule, you'd want to ask was the e-PHI used or disclosed? By or to whom? What documentation regarding the use and disclosure of e-PHI was maintained, or the other administrative requirements followed, or individual rights protected. Were the security requirements of the Security Rule met to have safeguards in place to ensure the confidentiality, integrity and availability of e-PHI. And I will add one other that is not on the screen, was a risk analysis performed? So, let's recap. The Security Rule is meant to complement the Privacy Rule in protecting e-PHI. It defines three types of safeguards: administrative, physical, and technical. A State Attorney General investigation should uncover whether a covered entity has implemented the security rule, standards and implementation specifications. Covered entities are required to implement specific safeguards to meet the requirements of each security standard to protect their information systems and the e-PHI they contain against threats and vulnerabilities, and to prevent unauthorized access or disclosure of e-PHI. So, let's do a quick recap of this Security Rule Module. We discussed the three objectives of the HIPAA Security Rule, which are confidentiality, integrity and availability, and the importance of ensuring the administrative, physical and technical safeguards are in place to protect the privacy of an individual's health information. This module also discussed the importance of conducting risk analysis as a critical first step in implementing a security compliance program. We introduced some HIPAA security-related key concepts, including “scalable,” “flexible,” and “reasonable and appropriate” as they relate to implementing safeguards to protect e-PHI. And finally, in our module, we described the elements of the HIPAA Security Rule, including security standards and implementation specifications—and the interrelationship between security and privacy. So, don't you feel empowered now that you can discuss the fundamental requirements of the HIPAA Security Rule, describe the HIPAA Security Rule standards and implementation specifications, and explain how the HIPAA Security Rule objectives and key concepts relate to building and evaluating a security compliance program. I want to thank you for your kind attention today and for your assistance in learning about this Module. I'm going to be in the back of the room for the rest of the day and would love to take any questions you may have about the exciting standards and specifications of the Security Rule.
(To use allow video to load completely)
  • Module 3: Introduction, Objectives and Overview
  • Lesson 1: HIPAA Security Rule Overview
  • Lesson 1: Recap
  • Lesson 2: HIPAA Security Rule
  • Lesson 2: Recap
  • Module 3: Recap and Summary

Tell a friend: