•

» healthcare information security

Meaningful Use, Risk Analysis and Protecting Electronic Health Information

Posted on January 4, 2011 by John Abraham in Main | 1 Comment

Registration begins this week for the Medicare and Medicaid Electronic Health Records (EHR) incentive programs. With the programs contingent on “meaningful use” of certified EHR technology, the big question now is how to achieve meaningful use. According to a mid-november survey by the College of Health Information Management Executives (CHIME) released on December 9, 2010, this won’t be easy:  “The vast majority of CIOs– 82 percent – report that they still continue to have concerns related to meeting meaningful use objectives and qualifying for stimulus funding.”

The Centers for Medicare & Medicaid Services (CMS) which administers the programs for the U.S. Department of Health & Human Services, will phase into meaningful use by defining 3 sets of criteria for achieving meaningful use over the next 5 years. The requirements for Stage 1 of meaningful use are defined by the CMS. While these vary for eligible professionals or eligible hospitals and critical access hospitals (CAHs), protecting electronic health information is a core objective that must be met to achieve EHR meaningful use for any entity.

CMS defines this core objective as follows:

Objective: Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.

Measure: Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.

A risk analysis is called out in 45 CFR 164.308 (a)(1)(A) as follows:

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.

HHS has provided some guidance on Risk Analysis which allows for some interpretation for compliance as noted in the following excerpts:

The guidance is not intended to provide a one-size-fits-all blueprint for compliance with the risk analysis requirement.

We understand that the Security Rule does not prescribe a specific risk analysis methodology, recognizing that methods will vary dependent on the size, complexity, and capabilities of the organization. Instead, the Rule identifies risk analysis as the foundational element in the process of achieving compliance, and it establishes several objectives that any methodology adopted must achieve.

The upside of the latitude provided is that if the spirit and intent of the Risk Analysis is maintained as an objective, a healthcare entity can leverage practical and cost effective approaches to achieving HIPAA Security Rule compliance, meaningful use, as well as minimize the risk of a HITECH Act data breach notification.

Here are a couple of resources for effective approaches to addressing the Risk Analysis requirement for meaningful use:

The diagram below adds some perspective to the Security Rule and Risk Analysis as it relates to HIPAA.


Healthcare Breach Fines – Legal defensibility and the implications for healthcare information security programs

Posted on June 21, 2010 by John Reno in Main | Leave a comment

Last week the media was buzzing with the actions of the California Department of Public Health (CDPH). The CDPH announced fines of $675,000 against six hospitals that had reported security breaches involving medical records. The legal basis for these fines and penalties are associated with two bills that amended California law in 2008, AB 211 and SB 541. Since the laws went into effect the CDPH has issued fines of $1.1M.

The major elements of the legal requirements associated with these laws include:

• Breach notification to the CDPH of unauthorized or unlawful access to and use or disclosure of medical information within 5 days after detection.
• A duty to prevent unlawful or unauthorized access to, and use or disclosure of medical information.
• An obligation to establish and implement appropriate administrative, technical and physical safeguards to protect the privacy of a patient’s medical information from any unauthorized access or unlawful access, use, or disclosure.
• Potential fines of $25,000 per patient ($17,500 per subsequent breach per patient) capped at $250,000 per event.

According to the American Health Information Management Association (AHIMA) 2,490 total incidents were reported in 2009 and 1,291 investigations were completed. Most of the reported incidents were unintentional breaches, but approximately 8% (191 incidents) involved malicious action by an insider or breach of an IT system.

Clearly this process is still in its early phases at the CPDH. But even at this early stage a number of things are clear. Healthcare organizations need to structure their processes to protect patient information. The information security team within the healthcare provider needs to assess the risks, develop a risk management program and deploy appropriate controls to protect the data as well as the systems and networks involved. Further, the security team needs to develop an incident response plan and work with their legal team to integrate legal defense considerations. Healthcare organizations that have proactively structured a security program where legal defense considerations have been well thought through will be in a much better position than those that are trying to conduct an investigation, analyze their options and construct legal arguments in the allotted five days.

Developing a proactive security program that works in close cooperation with the legal team as well as other organizations requires focused and consistent effort, but it is not new ground. The benefits also go far beyond simply being prepared for a CPDH investigation. Let’s look at a recommendation for a general process and framework for an information security program and it’s interaction with legal and other organizations. Shown below is a reference model with the primary organizations that the security team must interact with.

The objective of the security program is to minimize risk to information that is critical to the business while enabling business goals. The primary interactions in this area are with the line of business, finance and legal teams. The security team must codify the net results in terms of policy which will drive operational as well as quality and performance management decisions. Information security management is owned by the security team but interacts and primarily leverages operations, IT and HR. Information generated at this point contributes to the overall picture of situational awareness that guides both the business and the information security program. The security relevant aspects of quality and performance management for the business are owned by the security team but must work with the audit, development and QA teams. This function generates the reporting metrics (e.g. compliance to internal policies and regulatory requirements) that drives decisions for the business and the security team as well as contributes to the overall situational awareness picture. The overall output of this cycle is not simply to protect information but to allow better decisions to be made that drive the business forward.

So take it or leave it, but the guiding principle behind this view of a security program is one of leverage with other organizations, with business contribution as a driver. Let’s now look at some specifics behind working with the legal team, whether they are part of the internal organization or outside counsel.

Legal terms and language may be maddening to a technically oriented security team given the dependence on case law, room for interpretation and the interpretation of evidence. I don’t claim to be a lawyer, but I have checked with several in providing this guidance. The key here is not so much to lock on to a specific guideline, but to have some parameters for the conversation that you need to have with the legal team in advance of an incident. Let’s be clear, an incident will happen at some point. You will need a technically sound incident response plan. What I am suggesting is that you work with your legal team in advance and lock down a legally defensible plan as part of the information security program as well.

Now, since I have admitted that I am not an expert in legal defense let me guide you to one that I have developed a great deal of respect for on this subject. Please see the following article from David Navetta of the Information Law Group that was published recently in the ISSA Journal.

This topic of legal defensibility got started (in my mind) at the RSA conference this year. The leading contributor was Ben Tomhave. He pretty much gave momentum many of these ideas with his legal defensibility doctrine.

The problems of information security are hard. We need to cooperate with experts in many areas (legal and others) and not simply remain comfortable (even if we feel that technically we have covered the necessary bases).

« Previous   1 2