HIPAA Security Regulations: Risk assessment

It’s not easy but it’s doable if you proceed step-by-step

By Steven E. Fisher, MBA

This is the second article on the Health Insurance Portability and Accountability Act (HIPAA) Security Regulations. The first one (December 2004, Bulletin), is available on the AAOS Web site under both Library and Archives and Practice Management. This article focuses on how to conduct a risk analysis—one of the required Specifications within the Security Management Process Standard. The terms specification, standard and required all have precise meanings under HIPAA, as previously explained. Covered entities, which include most orthopaedic practices, must be in compliance with the Security Regulations by April 21, 2005.

The HIPAA Security Standards require each covered entity to:

• Ensure the confidentiality, integrity and availability of all electronic protected health information (EPHI) the covered entity creates, receives, maintains or transmits

• Protect against any reasonably anticipated threats or hazards to the security or integrity of the EPHI

• Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required by the Privacy Rule

• Ensure compliance by its workforce

For smaller offices, compliance may seem like an overwhelming task. In fact, it is simply a matter of developing a plan and following it.

The first thing you need to do, regardless of your practice’s size, is undertake a risk analysis. This only makes sense; you cannot make informed decisions about your EPHI until you have a thorough understanding of what you have, what potential threats you face and how likely these threats are to materialize.

The following step-by-step approach, based on the accompanying flowchart, will help you and your staff gain an understanding in these areas.

1. Document your system

First, document all of the information that you create, receive, maintain and/or transmit in electronic form. Start with the functions performed by each system (for example, “medical records” or “charge capture, billing and collection”). Then, for each function, describe the hardware, software and the interfaces (internal and external connectivity to other systems) as well as all the actual data maintained on the system. Finally, identify the people who actually use the system and those who support it.

2. Identify threats

List all possible threats to each of your systems, focusing on the most probable ones. Threats fall into three general categories: (a) acts of nature (such as floods, earthquakes or tornados); (b) acts of “man” (either intentional or unintentional); and (c) environmental events (such as a long-term power outage, pollution or chemical leakage). Although all environmental events can be classified as either acts of nature or acts of man, it is useful to isolate events such as power outages or chemical leaks from uncontrollable natural events in developing mitigating strategies. 3. Identify vulnerabilities Now, identify the areas where your systems are vulnerable. The best way to do this is first to identify what could happen (the nature of the vulnerability), such as someone seeing your data. Then identify who could break through your system (the source of the vulnerability) such as former employees or computer hackers. Finally, think about how they could cause the problem (the action that could be taken), such as by gaining access via a dial-up line. Vulnerability may arise because of a flaw in a given system’s basic design, in the way it was implemented or in its security procedures/protocols. You don’t need to examine all possible areas of vulnerability, only those that are most likely to result in a HIPAA violation.

4. Conduct a control analysis

Collect data on existing controls that you or a third party have implemented to prevent a HIPAA violation as well as controls you envision for the future. Controls fall into three categories, just as the HIPAA safeguards do: administrative (policies and procedures), physical (computer terminal privacy screens) and technical (password control access, data encryption).

It is not enough to document that you have implemented policies and procedures; you also need to determine that they are actually being followed. The best way to complete this step is to develop a series of checklists.

5. Determine likelihood

For each threat to each system, document whether the likelihood of that threat materializing is low, medium or high. The easiest way to do this is to assign a ranking to each level of likelihood—1.0 for low; 2.0 for medium and 3.0 for high.

6. Conduct an impact analysis

Look at the impact that a given threat can have if it actually occurs. Different threats will have different impacts. For example, if you were to lose the information in the system that handles charge captures, billing and collection and you did not have your data backed up, the impact on your business would be catastrophic, but it would not involve, per se, a HIPAA Privacy violation. You can quantify the degree of impact just as you quantified the threat level: 1.0 for low; 2.0 for medium; and 3.0 for high.

7. Determine risk

For each threat, create a grid using the values you assigned in determining the likelihood of threat and the potential impact. Consider the following grid, where the Likelihood is shown on the horizontal axis and the Impact is shown on the vertical axis. Based on a value of 1.0 for low, 2.0 for medium and 3.0 for high, the number in each cell is the product of the values assigned to the two variables

Clearly, the higher the score for a given threat to a given system, the greater your risk is. You should implement safeguards to mitigate or eliminate the system threats with higher rankings first, then move on to those with lower rankings.

8. Recommend controls

As the article in the December 2004 Bulletin explained, there are three sets of safeguards: administrative, physical and technical. In Step 4, you enumerated the controls you already have in place in these three arenas. Now, for each threat to each system, you should identify what additional controls you could implement to further mitigate, or completely eliminate, these threats.

In some cases, the Security regulations mandate that you implement certain safeguards. In other cases (the “addressable” specifications), you can choose whether or not to proceed with implementing the specification. This will depend on factors such as the level of risk, the nature of your organization (and whether the specification is even relevant to you) and the cost of implementing the specification.

9. Document results

Finally, you need to carefully document: (a) your systems and data, (b) the threats to your systems and data, (c) what you have done thus far to eliminate or mitigate the threats and (d) what you plan to do in the future and when. Because your systems and data will change over time (as will the threats to the systems and data), this documentation will need to be updated on a regular basis.

One more point: it’s a good idea to think of your Results Documentation not as something you’re “required to do” under HIPAA, but as a management tool in your office that will help ensure your business operations run smoothly in any event.

Steven E. Fisher, MBA, is manager, Practice Management Affairs at AAOS. He may be reached at (847) 384-4331 or sfisher@aaos.org

Additional Resources

• NIST Special Publication 800 Series: http://csrc.nist.gov/publications/nistpubs/index.html

• CERT/CC at Carnegie Mellon University: www.cert.org/stats/cert_stats.html

• Grove, T. Summary Analysis: The Final HIPAA Security Rule. HIPAA Advisory: http://www.hipaadvisory.com/regs/finalsecurity/summaryanalysis.htm

• Atlantic Information Services. The HIPAA Security Risk Analysis: It’s Good Business ... and It’s Required. Audio-conference on Tuesday, October 12, 2004

• Peltier, TR. Information Security Risk Analysis. New York: Auerbach Publications, 2001.

• Project COAST (Computer Operations, Audit and Security Technology), Purdue University: - OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation). www.cerias.purdue.edu/coast

• CSI/FBI Computer Crime and Security Survey (annual survey results): http://i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2003.pdf

• Alberts C and Dorofee A: Managing Information Security Risks, the OCTAVE Method. Boston: Pearson Education, 2003.

• ISO 17799:2000, Code of Practice for Information Security Management