HHS Releases Security Risk Assessment Tool

Need help performing your HIPAA/Meaningful Use Security Risk Assessment?  Good news, HHS has released a tool to help!  In partnership with the Office of the National Coordinator, HHS created a tool, user guide, software, tutorial, videos and even an iOS App to help HIPAA covered entities and business associates perform the required HIPAA Risk Analysis.

The HIPAA Security Rule specifically requires (this is not an addressable specification) a Security Risk Analysis:

“Risk analysis (Required). 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 or business associate.”  45 CFR 164.308(a)(1)

In addition, those hospitals and eligible professionals seeking to meet meaningful use in order to receive the EHR Incentive dollars or avoid the Medicare payment adjustments must fulfill a HIPAA Security Risk Assessment.

Stage 1

Stage 2

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. 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), including addressing the encryption/security of data stored in Certified EHR Technology in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the EP’s risk management process.

For those hospitals and eligible professionals looking to meet meaningful use, the Security Risk Assessment tool will generate a report that can be provided to auditors.  However, the report alone is likely insufficient because both the auditors and the  meaningful use requirements (above) require the correction of security deficiencies – so merely running a Security Risk Assessment without taking actions to remedy the problem will not suffice.  To read more about meaningful use audits and security risk assessments click here

In addition to releasing the Security Risk Assessment tool, HHS has created a helpful true/false statement with the Top 10 Myths of Security Risk Analysis.  This document highlights the misconceptions regarding the risk assessment requirements, including that all covered entities and business associates (regardless of the size) must conduct a risk assessment pursuant to HIPAA.  Importantly, though only eligible professionals & hospitals are eligible for meaningful use incentives and Medicare payment adjustments, business associates must also comply with the HIPAA Security Rule pursuant to the HITECH Act.  Therefore, business associates must also conduct security risk assessments, and per recent guidance from HHS, business associates are likely part of the next round of HIPAA audits.

For more information about HIPAA, security risk assessments, and meaningful use please contact Elana Zana.

Skagit County Agrees to Pay $215,000 for HIPAA Violations

On March 6, 2014, the U.S. Department of Health and Human Services, Office for Civil Rights (“OCR”) reached a $215,000 settlement with Skagit County in northwest Washington state for violations of the HIPAA Privacy, Security and Breach Notification Rules, according to terms of the Resolution Agreement.  This represents the first OCR settlement with a county government for HIPAA non-compliance. For two weeks in September 2011, the electronic protected health information (“ePHI”) for 1,581 individuals was exposed after the ePHI had been inadvertently moved to a publicly accessible web server maintained by Skagit County.  The accessible files included protected health information about the testing and treatment of infectious diseases.

The OCR investigation revealed that Skagit County failed to provide notification to individuals as required by the Breach Notification Rule and that the county failed to implement sufficient policies and procedures to prevent, detect, contain, and correct security violations. Further, Skagit County failed to provide necessary and appropriate security awareness and training for its workforce members.  As part of the settlement, the county has agreed to enter into a Corrective Action Plan to address deficiencies in various HIPAA compliance areas, including written policies and procedures, documentation requirements, training, and other measures.

This settlement highlights the importance for all covered entities and business associates, whether in the government or private sector, to implement policies and procedures to safeguard ePHI and, in case of a breach, to respond promptly and effectively. For more information about this OCR settlement or for assistance with HIPAA compliance, please contact Jefferson Lin or David Schoolcraft.

Upcoming HIPAA Audits Will Include Business Associates

On February 24, 2014, the Department of Health and Human Services (“HHS”) published a notice of its proposed collection of information in connection with its HIPAA audit efforts.  Comments on the proposed collection request must be submitted by April 25, 2014.

The notice indicates HHS’s intent to survey up to 1,200 organizations, including both covered entities and business associates, to determine the organizations’ suitability for HIPAA audits by HHS.  The survey will seek information about an organization’s patient visits, use of electronic information, revenue, and business locations, among other things.  The notice hints that some sort of technology will be used to complete the survey, as HHS’s time estimate of 30-60 minutes to complete the survey includes the time needed to “develop, acquire, install and utilize technology and systems for the purpose of collecting, validating and verifying information…”. The notice does not include details on the criteria HHS will use to select an organization for an audit.

One of the notable items of this notice is HHS’s announcement that this round of HIPAA surveys will include business associates as well as covered entites.  This is a clear signal that HHS is getting serious about HIPAA compliance by all organizations who handle protected health information.

For more information about HIPAA audits and HIPAA enforcement, please contact Lee Kuo.

The Business Associate Agreement Battle – Understand the Key Issues

The September 2014 deadline for amending pre-existing HIPAA business associate agreements (BAA) is fast approaching.  Are you ready?  Under the HITECH Act, covered entities and business associates have just under seven months to negotiate and implement amendments to all BAAs entered into prior to January 25, 2013.

In the face of the unprecedented challenge of revising all pre-existing BAAs, covered entities and business associates need to act quickly, but also be mindful of the important terms in BAAs that can lead to increased liability, including the following:

  • Indemnification: Although not required by the HITECH Act, covered entities often push for strong indemnification language that requires the business associate to indemnify the covered entity for a business associate’s breach of protected health information (PHI) and violations of HIPAA.  Acceptable indemnification language for each party depends on the nature of the PHI involved in the transaction and the amount of PHI that is transmitted between the parties. 
  • Limitation of Liability: In order to reduce the risks of receiving and maintaining the covered entity’s PHI, many business associates push for BAA language that limits their liability to a certain amount (i.e. fees paid by covered entity in the underlying agreement).  A covered entity’s acceptance to a business associate’s “limitation of liability” terms can pose significant risks if the business associate violates HIPAA after the BAA is signed. 
  • Breach Notification Time Period: The HITECH Act requires business associates to notify covered entities of a breach of PHI within 60 days of discovery.  However, in order to protect relationships with patients affected by a breach, proposed BAAs from covered entities generally require a business associate to provide notification within 10 days or less.  A business associate’s acceptance to a shorter notification period can put tremendous pressure on it to investigate and disclose accurate information after a breach occurs.

These are just a few terms found in BAAs that can lead to increased liability and risks for covered entities and business associates.  Although it is critical to complete BAA amendments by the September 23, 2014 deadline, business associates and covered entities need to think critically about the language in BAAs prior to signature.

If you would like more information about negotiating business associate agreements, please contact Dave Schoolcraft, Elana Zana or Casey Moriarty.

High Number of HIPAA Mobile Device Breaches – Time to Use Safe Harbor Encryption

Most breaches of electronic protected health information (ePHI) reported to the Department of Health and Human Services (HHS) have related to the theft or loss of unencrypted mobile devices. These breaches can lead to potentially hefty civil fines, costly settlements and negative publicity (e.g. Stanford and Idaho laptops or APDerm thumb drive). Given the increasing use of mobile devices and the significant costs of breach notification, healthcare organizations and their business associates would be wise to invest in encryption solutions that fall within the “safeharbor” for HIPAA breach notification.

Encryption and the “Safeharbor” for HIPAA Breach Notification

Under HHS guidance, ePHI is not considered “unsecured” if it is properly encrypted by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  Encryption processes “consistent with” (for data at rest) or which “comply, as appropriate, with” (for data in motion) the National Institute for Standards and Technology (“NIST”) guidelines are judged to meet the law’s standard for encryption.  If ePHI is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information—this is known as the HIPAA breach notification “safeharbor”. [78 FR 5664]

NIST Guidelines for Data at Rest

The NIST guidelines for data at rest do not provide specific requirements for encryption technology– instead, it describes common storage encryption technologies (full disk, volume, virtual, and file/folder encryption) and offers recommendations for implementing a storage encryption solution. A main takeaway from this guide is that “the appropriate encryption solution for a particular situation depends primarily upon the type of storage, the amount of information that needs to be protected, the environments where the storage will be located, and the threats that need to be mitigated.” Despite the lack of bright-line rules, the NIST guide does offer some key recommendations, such as:

  • When selecting a storage encryption technology, consider solutions that use existing system features (such as operating system features) and infrastructure.
  • Use centralized management for all deployments of storage encryption except for standalone deployments and very small-scale deployments.
  • Select appropriate user authenticators for storage encryption solutions.
  • Implement measures that support and complement storage encryption for end user devices.

Encryption Technology for Apple iOS Devices: A Case Study

The good news is that the technology is available to properly encrypt ePHI without being too burdensome.  For instance, Apple’s popular iPhones and iPads fortunately have their own built-in encryption technology.  Every iOS device has a “dedicated AES (Advanced Encryption Standard) 256 crypto engine built into the DMA (Direct Memory Access) path between the flash storage and main system memory, making file encryption highly efficient.”  Setting a passcode turns on Data Protection, and the passcode becomes a key to encrypting mail messages and attachments (or other apps), using 256-bit AES encryption. Notably, Apple’s encryption technology (CoreCrypto Module and CoreCrypto Kernel Module) has been FIPS (Federal Information Processing Standards) certified, a standard that the NIST guide references and approves.

Based on the NIST guidelines for data at rest, the following are some basic steps for implementing a storage encryption technology solution specifically with Apple iOS devices:

  • Ensure that users have up-to-date devices and operating systems (e.g. iPhone 4 or higher running iOS 4 or higher).
  • Work with an IT administrator or security expert to manage deployment of iPhones.
  • Select appropriate passcode requirements to meet your security needs, including timeout periods, passcode strength and how often the passcode must be changed. The effectiveness of data protection depends on a strong passcode, so it is important to require and enforce a passcode stronger than 4 digits when establishing passcode policies.
  • Store/transmit the minimum amount of ePHI necessary to effectuate communication.
  • Disable access to Notification Center and Alerts from locked screen to prevent display of potentially sensitive data.
  • Revise and document organizational policies as needed to incorporate appropriate usage of the storage encryption solution.
  • Make users aware of their responsibilities for storage encryption, such as physically protecting mobile devices and promptly reporting loss or theft of devices.

For additional guidance on mobile device security, the HHS Office of the National Coordinator for Health Information Technology (“ONC”) has also provided helpful tips in “How Can You Protect and Secure Health Information When Using a Mobile Device?”.

As healthcare becomes more mobile, covered entities, business associates, and health information technology vendors should become familiar with the “safeharbor” for HIPAA breach notification and the NIST guidelines for encryption of data at rest and in transit.  For more information about the HIPAA “safeharbor”, encryption standards, or HIPAA in general, please contact Jefferson Lin, Lee Kuo or David Schoolcraft.

 

HHS Issues HIPAA Guidance For Mental Health

HHS recently issued HIPAA guidance for mental health practitioners, in an effort to help providers wade through complicated decisions of when disclosures of patient information are permissible.  This guidance, set up in a FAQ format, is designed to incorporate common questions related to the intersection of mental health and privacy laws.  The guidance addresses when healthcare providers are permitted to:

  • Communicate with a patient’s family members, friends, or others involved in the patient’s care;
  • Communicate with family members when the patient is an adult;
  • Communicate with the parent of a patient who is a minor;
  • Consider the patient’s capacity to agree or object to the sharing of their information;
  • Involve a patient’s family members, friends, or others in dealing with patient failures to adhere to medication or other therapy;
  • Listen to family members about their loved ones receiving mental health treatment;
  • Communicate with family members, law enforcement, or others when the patient presents a serious and imminent threat of harm to self or others; and
  • Communicate to law enforcement about the release of a patient brought in for an emergency psychiatric hold.

The guidance also addresses FERPA (privacy laws in a school setting), Federal alcohol and drug abuse confidentiality (42 CFR Part 2 Programs) and the rights of parents to have access to a minor child’s information.    Though not addressed in the guidance, those mental health practitioners practicing in Washington State should also be aware of  the new statutes regulating mental health record disclosures which take effect on July 1, 2014.

For assistance in navigating these privacy rules please contact Elana Zana or Dave Schoolcraft.

HHS Deadline for HIPAA Breach Notification Reporting

As part of the HITECH revisions to HIPAA, providers are required to report all HIPAA breaches, regardless of the number of individuals affected to HHS on an annual basis.  The deadline for this report is Saturday, March 1st, 2014.  This reporting requirement is pursuant to the Omnibus HIPAA Rule published in January of 2013.  Providers who have had breaches affecting less than 500 individuals can report the HIPAA breaches here.  This report needs to be filled out for each breach that occurred during the 2013 calendar year.  For example, if a covered entity had a breach in April of 2013 affecting three individuals and another breach in December 2013 affecting two individuals the report must be submitted for each breach but not for each individual (a total of two reports would be submitted in this example).  To fill out this form covered entities will need to submit the following information about the breach:

  • General information regarding the covered entity
  • Whether the breach occurred at or by a Business Associate and the associated contact information for that Business Associate
  • Date of the Breach
  • Date of Discovery
  • Approximate number of individuals affected by the Breach
  • Type of Breach (i.e. theft, loss, unauthorized access, etc.)
  • Location of breached information (i.e. laptop, e-mail, etc.)
  • Type of Protected Health Information involved in the Breach (i.e. demographic, financial, etc.)
  • Description of the Breach
  • Safeguards in place prior to the Breach (i.e. firewalls, physical security, etc.)
  • Date individuals were notified of the Breach
  • Whether substitute notice was required (this requirement is described in the rule)
  • Whether media notice was required (this requirement is described in the rule)
  • Actions taken in response to the Breach (sanctions, mitigation, etc.)
  • Any additional actions taken
  • Attestation

For those covered entities that have had a breach which affected more than 500 individuals, this report should have been submitted no later than 60 days following discovery of the breach in accordance with the Breach Notification Rule.

If you have questions regarding filling out this report or on Breach Notification in general please contact Elana Zana or Dave Schoolcraft.

Proposed HIPAA Rule to Enhance Criminal Background Check System

On January 7, the U.S. Department of Health & Human Services (HHS) published a notice of proposed rulemaking (NPRM) to revise the HIPAA Privacy Rule expressly permitting certain covered entities to disclose specific information about individuals who are subject to the federal mental health prohibitor to the National Instant Criminal Background Check System (NICS). HHS stated the purpose of this amendment is to help “strengthen the federal background check system to keep guns out of potentially dangerous hands” by removing legal barriers under HIPAA that may prevent reporting relevant information to the NICS.

The NICS is a national system used to conduct background checks on individuals who may be disqualified from purchasing or receiving firearms based on federally prohibited categories or state law. One such category is the federal “mental health prohibitor,” which includes individuals who have been (1) involuntarily committed to a mental institution; (2) found incompetent to stand trial or not guilty by reason of insanity; or (3) determined by a court, board, commission, or other lawful authority to be a danger to themselves or others or to lack the mental capacity to contract or manage their own affairs.

The proposed amendment would permit HIPAA covered entities that perform the commitments or adjudications that make individuals subject to the federal mental health prohibitor, or that act as repositories of NICS records on behalf of a state, to use and disclose certain information for NICS reporting purposes. These select covered entities would be permitted to disclose only  the “individual’s name; date of birth; sex; a code or notation indicating that the individual is subject to the Federal mental health prohibitor; a code or notation representing the reporting entity; and a code identifying the agency record supporting the prohibition.” Covered entities would not be permitted to disclose clinical or diagnostic information, medical records, or other identifiable health information. Covered entities could disclose the information directly to the NICS or to an entity designated by a state as a data repository for NICS reporting purposes.

Because the proposed rule focuses on covered entities that actually are responsible for ordering involuntary commitments or conducting adjudications, or that act as a designated repository of NICS records, it does not affect most treating providers or covered entities that only engage in treatment functions. Further, this modification would permit, not require, the specified covered entities to disclose information.  The proposed amendment would not include any additional notification requirements to individuals whose information was disclosed and would not require covered entities to change their notice of privacy practices.

HHS is seeking comments, which are due on March 10, on various issues addressed in the NPRM, including whether the permission should be broadened to include reporting on individuals subject to state firearms prohibitions and additional (non-clinical) identifying information.

For more information about the proposed rule or HIPAA in general, please contact Jefferson Lin.

Stolen Thumb Drive Proves Costly for Dermatology Practice

The Department of Health and Human Services (HHS) recently announced a $150,000 settlement with a dermatology practice in Massachusetts that arose out of a stolen thumb drive.  The unencrypted drive, which contained the health information of approximately 2,200 individuals, was stolen from a vehicle of one of the practice’s staff members.

Although HHS was concerned with the staff member’s failure to safeguard the health information, the large settlement amount resulted primarily from the practice’s lack of HIPAA policies and procedures.  Specifically, HHS determined that the practice: (1) had no breach notification policies, (2) had not conducted risk assessments for potential security vulnerabilities, and (3) did not adequately perform HIPAA training for its workforce.

This case provides an important warning to health care providers who do not have comprehensive HIPAA and HITECH policies and procedures.  Although the risk of being selected for an HHS HIPAA audit is still relatively low, it only takes one breach of health information for HHS to open an investigation that can result in costly penalties.

For more information about HIPAA and HITECH policies and procedures, please contact Casey Moriarty.

 

Meaningful Use Audits – Security Risk Analysis

‘Tis the season for Meaningful Use, the time of year when eligible professionals (EPs) and eligible hospitals (EHs) compile their data from the meaningful use measures and prepare for attestation.  It is also the season of meaningful use audits.  A lesson learned from recent audits: CMS means what it says – EPs and EHs must conduct a security risk analysis.  This measure is not one to be taken lightly – it’s a HIPAA requirement, and CMS auditors are on the lookout for documentation (remember, all documentation must be retained for 6 years).

Regardless of whether EPs or EHs are attesting to Stage 1 or Stage 2, or the fact that they performed a security risk analysis last year, this objective and measure must be fulfilled each year:

 

Stage 1

Stage 2

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. 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), including addressing the encryption/security of data stored in Certified EHR Technology in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the EP’s risk management process.

The HIPAA requirement for a Security Risk Analysis pursuant to 45 CFR 164.308(a)(1) is as follows:

“Risk analysis (Required). 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 or business associate.”

CMS Meaningful Use audits have specifically called out this objective and measure and are requiring participants to prove that a Security Risk Analysis has actually occurred.  Though the HIPAA Security Officer should have conducted a security risk analysis for the entire practice/hospital, EPs and EHs should maintain a copy of this assessment with their meaningful use documentation and should review the assessment to make sure that the risk analysis complies with the meaningful use requirements (note: the Stage 2 requirements are significantly broader).

Below is the audit question that was sent to some Stage 1 EPs:

“Provide proof that a security risk analysis of Certified EHR Technology was performed prior to the end of the reporting period (i.e. report which documents the procedures performed during the analysis and the results of the analysis).  If deficiencies are identified in this analysis, please supply the implementation plan; this plan should include the completion dates.”

Note that the audit request indicates that further documentation is needed to satisfy the auditors.  EPs must show the implementation plan and the completion dates.  As per the measure itself, the requirement is not merely to conduct a security risk analysis, but the EPs and EHs must implement security updates and correct security deficiencies.  EPs and EHs should document these steps as well in order to appropriately respond to an audit request.

CMS has recently issued a new tip sheet to assist EPs and EHs in fulfilling the security risk analysis requirement.  In addition ONC has published guidance on HIPAA Security Risk Analysis requirements.  The CMS tip sheet includes some common myths surrounding risk analysis such as:

  • “I only need to do a risk analysis once.”

False. To comply with HIPAA, you must continue to review, correct or modify, and update security protections.

  • “My EHR vendor took care of everything I need to do about privacy and security.”

False. Your EHR vendor may be able to provide information, assistance, and training on the privacy and security aspects of the EHR product. However, EHR vendors are not responsible for making their products compliant with HIPAA Privacy and Security Rules. It is solely your responsibility to have a complete risk analysis conducted.

  • “The security risk analysis is optional for small providers.”

False. All providers who are “covered entities” under HIPAA are required to perform a risk analysis. In addition, all providers who want to receive EHR incentive payments must conduct a risk analysis.

  • “Simply installing a certified EHR fulfills the security risk analysis MU requirement.”

False. Even with a certified EHR, you must perform a full security risk analysis. Security requirements address all electronic protected health information you maintain, not just what is in your EHR.

Responding to a Meaningful Use audit can be time consuming and very detailed oriented — thus, maintaining the appropriate documentation is essential.  For assistance with Meaningful Use or HIPAA security risk assessments, please contact Elana Zana.