Leon Rodriguez, JD: Hello. I'm Leon Rodriguez, Director of the Office for Civil Rights at the US Department of Health and Human Services. I would like to welcome you today to this program titled "Understanding the Basics of HIPAA Security Risk Analysis and Risk Management."

The goals of this program are to review the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule-required implementation specifications for risk analysis and risk management, highlight the basic concepts involved in security risk analysis and risk management, and discuss the general steps involved in risk analysis and risk management.

Let's talk about some key concepts. The first is the concept of electronic protected health information (ePHI). This is information that is created, received, maintained, or transmitted by your office and kept in an electronic form. It is subject to the Security Rule, which is one of the rules issued under the HIPAA law. As an HIPAA-covered entity, you are required to have in place reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of your ePHI.

Risk analysis is the first step in the Security Rule compliance efforts for your practice, and it is part of an ongoing process to provide you with a detailed understanding of the risk to the confidentiality, integrity, and availability of your patients' information. Now remember, this is really important to your patients. They trust you to keep their information confidential and secure, so by conducting this risk analysis, you provide them the assurance that their information is going to be safe, confidential, and secure.

Risk analysis is one of the 4 implementation specifications required under the Security Rule for implementing what we call the security management process standard.

The rule requires covered entities to evaluate risks and vulnerabilities in their work environments and to implement reasonable and appropriate steps to protect against reasonably anticipated threats or hazards to the security or integrity of ePHI. Risk analysis is the first step in that process of evaluating.

We have 2 different kinds of requirements under HIPAA. Some are actual requirements. When we talk about, for example, risk analysis, we are talking about something that is required under any circumstance of a covered entity. We also have requirements that are called addressable requirements. These are not optional requirements; rather, your organization must determine whether it can, in a reasonable and appropriate manner, implement that addressable requirement. If you cannot, you need to document why, and you also need to take steps that are about as good as the actual requirement to be in compliance with the rules.

The risk analysis is going to inform the compliance program for your office or practice. The outcome is essential to developing various policies, procedures, and practices for your compliance programs. Some examples of these policies and procedures might be personnel screening processes. In other words, as you hire people into your practice, you need to know that (1) they are people who are competent to handle the kinds of confidential information that you have in your practice and (2) that they are actually people who you can trust with this sort of confidential information. There are all too many examples of employees of healthcare providers who, for economic or other reasons, disclose information that is confidential regarding the patients in the medical practice.

Part of the compliance program also needs to identify what data you need to back up and what methodologies you need to use to back up that data. You need to decide whether and how to use encryption. Let's talk for a second about what we mean by encryption. Encryption is a way of scrambling electronic information so that it is unreadable to someone who does not have the authority to read that information. Along with an encrypted document or file is what we call a key, which gives you the method for opening that file. Encryption is an example of one of those addressable requirements we discussed earlier -- something that is ordinarily an expectation for providers but, in situations where it is either unworkable or too expensive, something that you need to document why you did not use encryption and why you are using another methodology, such as password protection.

Another step in the compliance program is to address what data need to be authenticated in particular situations to protect its integrity. Finally, you need in general to determine the appropriate manner of protecting health information transmissions -- in other words, transmissions of health information, either within your office or from your office to, for example, an insurance company or to another provider's office.

Let's talk, first, about what we mean by "vulnerability." When it comes to the HIPAA Security Rule, vulnerability is a flaw -- a weakness in system security procedures, design, implementation, or internal controls that could result in a breach or a violation. Now, when we talk about a flaw or weakness, whenever we are talking about a system that people are going to use, that people are going to view, that in and of itself is inherently a flaw. At the same time, though, that flaw is necessary for you to be able to use that system. When we talk about vulnerabilities, it does not necessarily mean that something is broken or not working; rather, it is a point at which we need to take steps to maximize the degree to which we protect a particular piece of information, a particular piece of equipment from unauthorized use.

There are 2 general categories of vulnerabilities. One is nontechnical vulnerabilities. A nontechnical vulnerability may include an ineffective or nonexistent policy, procedure, standard, or guideline. Technical vulnerabilities may include holes, flaws, or weaknesses in the development of information systems or incorrectly implemented and/or configured information systems. Again, we come back to the basic point. Vulnerability is meant to have the common sense definitions that it has in ordinary use.

Now what do we talk about when we are talking about a "threat"? A threat is the potential for a person or a thing to exercise a specific vulnerability either accidentally or intentionally. In other words, a threat is the potential to trigger a specific vulnerability. Threats can be grouped into general categories, such as natural threats, human threats, and environmental threats. For example, 1 category of a natural threat is a fire, something that may occur outside of your office but really poses a potentially long-term risk to the protected health information that may be in your office. A human threat might be something like theft or snooping, which is going to require different kinds of safeguards. Finally, an environmental threat, somewhat similar to a natural threat, could be something like a power failure or some sort of act of war, which, again, could compromise the systems within your office.

As we move along this common sense continuum, the next concept we talk about is "risk." Risk is the probability that a particular threat will accidentally trigger or intentionally exploit a particular vulnerability. Remember what we talked about. We started by talking about a vulnerability -- that is, a hole or gap. We talked about a threat, which is the possibility of exploiting that hole or gap. Risk, now, is really talking about the probability that that hole or gap is actually going to be exploited or compromised in some way.

Risk has 2 components. It is a function of the likelihood of a given threat triggering or exploiting a particular vulnerability and the resulting impact on your organization. For example, you may have a risk that is highly likely to occur but the impact is relatively minor. At the same time, you may have a risk that has a comparatively low likelihood of occurring, but the impact could, in fact, be devastating to your organization. In either of these scenarios, you have a risk about which you need to be mindful in your risk analysis program.

There are many ways of performing a risk analysis. In the security world, there is not a particular best practice. As we talk about the Security Rule, you will hear us use the concept of the Security Rule as being scalable and flexible. We understood, when we wrote the Security Rule, that we would be creating a rule that would be applicable to many different kinds of entities. Some of you are solo practitioners in single physician's offices. Others of you work in clinics, and others of you work in large hospital systems; the rule often will operate differently in each of your environments. For that reason, the rule does not prescribe any particular technology, technique, or practice for performing risk analysis. Rather, what it really identifies is a common sense process for how that analysis will take place. That does not mean that there are not some significant resources out there to help you in conducting the risk analysis. For example, if you come to our Office for Civil Rights website, which I will discuss later, there are links to a number of places, including something called the "Security Risk Tool Kit," which is put out by the National Institute of Standards and Technology, which gives you some tips and guidelines as to how you can implement a risk analysis under the Security Rule. There are many examples of steps that can be applied when you undertake your risk analysis process.

There are certain key elements of that risk analysis process, and the first thing is to identify the scope of your risk analysis. That scope should encompass the potential risks and vulnerabilities to the confidentiality, availability, and integrity of all the ePHI that your organization creates, receives, maintains, or transmits. That includes ePHI in all kinds of electronic media.

Let's talk about some of the places where ePHI could be found. One very significant place for such information is in biomedical devices, things like physiological monitors, infusion pumps, ventilators, magnetic resonance imagers, computed tomography scanners, ultrasound equipment, and laboratory analyzers. All of these kinds of devices both create and maintain ePHI, and these devices are vulnerable while they are in your office and in use in your office but also whenever a lease, for example, ends and you return those devices to the company that leased them to you.

We had an example recently of an enforcement case in the Office for Civil Rights in which a practice leased a photocopy machine. In this day and age, digital photocopy machines retain much of the data that come from the items that are imaged on that machine. In this particular case, the photocopy machine was actually returned to a major national television network, which then let the whole world know that this particular medical practice had returned what otherwise should have been protected patient information.

Other places where that ePHI can be found are in mobile devices, such as cell phones, smartphones, PDAs, and tablets. Increasingly, physicians are using those devices both to work on the electronic information in the course of their practice and, critically, to be able to communicate with their patients. Legacy magnetic media that you may have used historically in your practice include floppy drives; Zip drives; magnetic tablets; hard drives; optical media like CDs and DVDs; removable media such as pen drives, thumb drives, and flash drives, that sort of thing; memory cards; embedded memory on boards and devices; and RAM- and ROM-based storage devices. These are some of the many different examples of where electronic health information might be found.

What your organization needs to do as part of the risk analysis is to determine all of these places where ePHI is stored, received, maintained, or transmitted. As part of that data collection exercise, you need to review past and existing projects that may give you a clue as to where ePHI might be. You probably need to interview key staff in and around your office. You need to review whatever documentation you have in your office that, again, will give you critical information as to the location and nature of this ePHI. You may use other data-gathering techniques, as situations and common sense dictate.

Once you have gathered those data, you need to identify and document, and you are going to hear us use the word "document" a lot. You need to write down every step that you take. Here, we are talking about documenting reasonably anticipated threats to ePHI. It is likely that, as you do your risk analysis, you will identify different threats that are unique to the circumstances of their environment. An example is the different threats to ePHI that are in your office or occur when your staff works from home. Let me highlight that last point, because that is something that we see a lot in the Office for Civil Rights: threats to ePHI that is removed from the physician's offices, things like laptops or PDAs that are taken home, through all good intention, for an employee or a provider to be able to work at home using that information. Unfortunately, when information is removed from the office, it is very often vulnerable to theft or loss. We have seen examples of laptops being stolen from an automobile, of records being stolen while an employee was riding on public transportation. You need to think about what you need to do to secure that information when it leaves your office for these purposes.

You also need to identify and document vulnerabilities that, if triggered or exploited by a threat, could create a risk of inappropriate access to or disclosure of ePHI. In other words, this is the same scenario we talked about before, where you could have theft or loss of protected health information.

Once you have identified all those risks, threats, and vulnerabilities, the next step is to look at your existing security program. You need to assess and document the security measures that you are using to safeguard ePHI, whether these are actually measures required by the Security Rule or if they happen to just be the current security measures that you have configured and are properly using.

Once you have identified what those are, you need to determine if they are sufficient, given the particular circumstances of your office or your particular business process, to protect all the different types of ePHI that you have identified as existing in your office and that you have also identified as being vulnerable. As we said before, the Security Rule is meant to be scalable and flexible to the particular nature and size of your practice, so the kinds of security measures that you are going to take will vary, depending on your type of practice.

Once you have completed the risk analysis, the next step is to engage in the process of risk management. Risk management is the actual implementation of security measures to sufficiently reduce your organization's risk of losing or compromising its ePHI and to meet the general security standards. We have other training modules that delve in detail into the various security steps that you need to take to protect ePHI. We ordinarily talk about administrative, physical, and technical safeguards. "Physical" is what you need to do in terms of how your information is physically housed. "Administrative" relates to procedures, and "technical" concerns those electronic measures you need to take to protect that information. Whatever you need to do, your risk management process needs to be updated on a regular basis.

You also need to engage in ongoing self-audits. It is not enough just to do that initial risk analysis exercise; rather, you must, at some reasonable interval -- possibly annually, semiannually, biannually, depending on what is right for your practice -- engage in the process of self-assessment and self-audit, to make sure that you are continuing to protect that information in the best way possible. This is particularly true when you acquire new technology for your practice or, for example, when you move your practice. When you have identified new risks in this process, you need to address those risks in a timely manner to make sure that your technology and business operations are properly updated.

Let me wrap up with a few important thoughts. First, compliance with the HIPAA Security Rule is more than just binders up on a shelf. It is really meant to be an active, ongoing, thoughtful, intentional process of risk analysis, risk management, and routine reviews. These are the cornerstones of an effective compliance program and your best defense in safeguarding your patients' information.

There is more helpful information about this on our website, and we ask you to visit Office for Civil Rights. We will have additional guidelines, tips, and pointers and links to wonderful sources of information on how to comply with the common sense Security Rule.

Thank you for participating in this activity. You may now take the CME posttest by clicking on the Earn CME Credit link. Please also take a moment to complete the program evaluation that follows.