HIPAA Audit Program Phase II – Have You Been Selected?

HIPAAAuditProgram

Phase II of the HIPAA Audit Program has begun, with many covered entities and business associates receiving a “Audit Entity Contact Verification” message from the Department of Health and Human Services (HHS) and the Office of Civil Rights (OCR). The communication requires the individual recipient to verify that he or she is the primary contact for the HIPAA Audit Program.

Does the receipt of this form mean that your entity has been selected for an audit? Not necessarily.

Although receipt of the communication is not a guarantee of an audit,  it is the first step in a process that may lead to a comprehensive HIPAA compliance audit of your entity.  According to OCR, the process for the HIPAA Audit Program is as follows:

  1. Contact Verification: OCR will send the Audit Entity Contact Verification to a covered entity or business associate to determine the entity’s primary contact for HIPAA purposes. Covered entities and business associates who receive the form should respond and not ignore the OCR’s request for verification.  The OCR has made it clear that entities who do not respond could still be subject to an audit.
  1. Questionnaire: After the entity’s contact information is verified, the OCR will send a questionnaire to each covered entity and business associate to determine the size, type, and operations of the entity.  Covered Entities will also be required to identify each of their business associates. OCR will use this data to develop the pool of potential auditees for the HIPAA Audit Program.
  1. Selection: OCR will then randomly select entities from the pool for audit.  If selected, the entity will have to visit an OCR web site and upload its HIPAA privacy policies, security policies, and most recent risk assessment. Based on the information uploaded, it is possible that OCR will arrange for an on-site visit of the entity.

The bottom line is that your receipt of the Audit Entity Contact Verification message does not necessarily mean that your entity will be selected for a HIPAA audit.  However, your entity will likely be placed into the pool from which OCR will select entities to audit.

If nothing else, the receipt of the Audit Entity Contact Verification communication should motivate your entity to review current HIPAA privacy and security policies and ensure that they conform to the requirements of HIPAA and the HITECH Act.  In addition, your entity should perform an updated risk analysis to uncover and address gaps in your HIPAA security policies and procedures.

A basic risk analysis should include the following components:

  1. Inventory: An inventory listing all of your information assets that contain health information (e.g. computers, laptops, smartphones, etc.);
  2. Threats: Potential threats to the security of your information assets;
  3. Controls: Current controls to safeguard the assets against the threats;
  4. Vulnerabilities: Any vulnerabilities in the controls;
  5. Likelihood: The likelihood that the threats will exploit the vulnerabilities;
  6. Impact: The impact if the vulnerabilities are exploited (e.g. how much health information is at risk); and
  7. Risk: The overall risk of a threat based the likelihood and potential impact of the threat’s exploitation of a vulnerability.

It is important to develop policies and procedures to address any risks that your entity uncovers as a result of the risk analysis.

Although the HIPAA Audit Program can be a source of anxiety for covered entities and business associates, it can also be a great opportunity to update HIPAA policies and procedures and ensure that your entity is doing everything possible to safeguard health information.

For more information about the HIPAA Audit Program and HIPAA compliance issues, please contact Casey Moriarty.

Stolen Laptop Costs Research Institute Millions

The Feinstein Institute for Medical Research (Feinstein) recently agreed to pay, the U.S. Department of Health and Human Services, Office for Civil Rights (OCR), $3.9 million to settle allegations that Feinstein violated the HIPAA Privacy and Security Rules. This settlement confirms the OCR’s position that nonprofit research institutes are held to the same standards as all other HIPAA covered entities.

The OCR began its investigation, after Feinstein filed a breach report revealing that a laptop computer containing electronic protected health information (ePHI) had been stolen from an employee’s car. The laptop contained the ePHI of approximately 13,000 patients and research participants. The laptop was unencrypted.
In addition to the breach, OCR’s investigation determined that Feinstein failed to:

(1) conduct a risk analysis of all of the PHI held at Feinstein, including the PHI on the stolen laptop;

(2) implement policies and procedures for granting access to ePHI to workforce members;

(3) implement physical safeguards for the laptop;

(4) implement policies and procedures managing the movement of hardware that contains ePHI; and

(5) implement encryption technology or to ensure that an alternative measure to encryption was deployed to safeguard the ePHI.

HIPAA does not expressly require encryption of ePHI, however, covered entities and business associates, who do not encrypt ePHI, are required to document why encryption is not reasonable or appropriate. Covered entities and business associates that do not encrypt ePHI are also required implement measures equivalent to encryption to safeguard ePHI.

 
In addition to other violations, the OCR’s investigation revealed that Feinstein failed to document why encrypting the laptop was not reasonable or appropriate. Further, contrary to having measures equivalent to encryption for safeguarding ePHI, the OCR found that Feinstein lacked policies and procedures for the receipt and removal of laptops containing ePHI from its facilities and policies and procedures for authorizing access ePHI.

 
This settlement provides us with three lessons. First, it’s important to realize that research institutes are held to the same standards as other covered entities. To the extent a research institute maintains PHI, it is essential to develop adequate policies and procedures to protect the PHI. Failing to do so, exposes the institute to considerable risk. Second, encrypting ePHI goes a long way towards reducing liability. Had Feinstein’s laptop been encrypted to the NIST standard, Feinstein’s ePHI would have been secured and Feinstein wouldn’t have been required to report a breach. Instead, as is often the case, the OCR’s investigation revealed multiple additional HIPAA violations. By not encrypting ePHI covered entities and business associates risk not only the cost of a breach, but also the potential for added costs following an OCR investigation. Lastly, covered entities and business associates that don’t encrypt their ePHI, are required to document why encryption is not reasonable or appropriate. Failing to do so is a HIPAA violation and subjects covered entities and business associates to liability.

Ready for an OIG Security Audit?

At HIMSS15 in Chicago I had the pleasure of speaking with my colleague, Dave Schoolcraft, regarding the OIG Security Audits. These in depth security audits conducted not by the OCR or CMS, but rather the Office of Inspector General, delve into the security systems of Eligible Hospitals (and potentially Eligible Professionals) participating in the EHR Incentive Program.

Background

The OIG in its 2014 and 2015 Work Plans identified its plan to audit participants in the EHR Incentive Programs and their business associates, including cloud service providers, “to determine whether they adequately protected electronic health information created or maintained by certified EHR technology.” This audit stretches beyond a typical meaningful use audit and is not only centered on the security of ePHI stored in the CEHRT, but also looks at relationships with downstream service providers. Though EPs and EHs that participate in the EHR Incentive Program are aware of pending audits from CMS (via Figliozzi & Company), including the necessary documentation and security risk analysis requirements, these audits may come as quite a surprise – especially the level of thoroughness the OIG pursues in these audits. Though the OIG identifies the targeted entities due to their participation in the EHR Incentive Program, these audits look nothing like a CMS audit but instead are an in-depth HIPAA security audit.

The Audit

The audit itself is conducted by OIG investigators that are knowledgeable about security infrastructure as well as HIPAA requirements. The OIG commences the audit with a phone call followed by a formal letter notifying the recipient entity of the audit. As stated in its letter “the objective of [the] audit is to assess if the [hospital’s] meaningful use requirements have protected the confidentiality, integrity and availability of electronic protected health information (ePHI) in its EHR systems.” The OIG sends out a document request/questionnaire with approximately 17 categories and subcategories that it is investigating. In addition to reviewing the responses to the document requests the OIG auditors come on-site for 2-3 weeks to conduct interviews and personally review the security infrastructure.

Sample audit questions include:

  • Review of the EHR network diagram that shows EHR network architecture including external connections.
  • Provision of a description of internal or external web sites associated with the EHR system including patient portals.
  • Analysis of existing HIPAA policies and procedures, including patch management and access controls.
  • Detailed description of EHR network devices including the manufacturer and model number, software version and primary function.

As stated in the OIG Workplan, the target of the investigation is not only the covered entity itself, but also the relationships with business associates and downstream cloud service providers.

Audit Readiness Plan

It is unknown how many audits OIG will conduct and the ultimate goal of these audits. We believe that the OIG plans on creating a roll-up report to describe the findings of these audits, rather than publishing individual reports – however this has not been verified because the OIG has denied Freedom of Information Act requests.

We recommend that covered entities prepare for these audits as follows:

  • Gather information regarding existing security infrastructure in place, including relationships about sharing PHI with business associates and downstream providers.
  • Evaluate health IT vendors to determine if they are compliant with business associate agreements – this may include asking the business associate to provide you with evidence and results from a security risk assessment.
  • Identify team members that will respond to an OIG audit request.
  • Conduct a mock audit to fully assess security.

Additional Audits

 The OIG Work Plans also identify three other related types of audits.

 

  1. OIG Audits of Medicare EHR Incentive Program. Earlier this month the OIG issued a number of multi-year audits of EHR Incentive Program participants. These audits are very similar to the CMS Meaningful Use audits conducted by Figliozzi, but are in fact not conducted by CMS. Unlike the CMS audits however, the OIG audits are multi-year and may request information from both Stage 1 and Stage 2 attestations.

 

  1. OIG Audits of Medicaid EHR Incentive Programs. OIG has conducted at least three audits of states issuing Medicaid EHR Incentive Program dollars: Louisiana, Massachusetts and Florida. Of the three audited, only Florida was found to have issued the EHR Incentive Program dollars correctly. The OIG has instructed the other states to reimburse the federal government for the incorrectly distributed funds and adjust the payment calculations for the hospitals going forward.

 

  1. OIG Audits of Contingency Plans. Pursuant to the HIPAA Security Rule, covered entities must have contingency plans in place in case of a disaster or other occurrence that damages systems that contain ePHI (45 CFR 164.308). The OIG plans to compare hospitals’ contingency plans with “government and industry recommend practices.”
  2. OIG Audits of AIU Participants.  OIG has recently issued new audits investigating AIU attestations.  For further detail related to these audits go to:  http://meaningfuluseaudits.com/oig-escalates-meaningful-use-audits-of-hospitals/.

 

Preparing for these OIG audits can be accomplished during your own internal Security Risk Analysis and can be a useful tool for verifying the accuracy and thoroughness of your own process. For more information about the OIG Security Audits or other OIG audits please contact Elana Zana or Dave Schoolcraft.

 

You’ve Been Sued: 4 Non-HIPAA Claims in Data Breach Cases

“There is no private right of action under HIPAA.”  This oft-repeated rule is a source of comfort for many health care entities.

Of course, patients can file complaints with the Office of Civil Rights or State Attorneys General, but a “HIPAA cause of action” does not exist.

So what is the basis for the many different class action lawsuits against health care entities that have been hit with data breaches? The recent class action lawsuit filed against Premera sheds some light on strategies of class action attorneys.

The Complaint alleges seven different causes of action.  This article will focus on four of the claims.

The Four Causes of Action in the Premera Complaint

  • Negligence: The first cause of action is negligence. To establish a claim for negligence, the plaintiff must show that an entity: (1) had a duty to the plaintiff, (2) the entity breached the duty, (3) the plaintiff suffered damages, and (4) the entity’s acts caused the damage.

    The Complaint states that Premera had a “duty” to keep the plaintiffs personal information secure as the provider of health coverage to the plaintiffs.  Premera breached this duty by failing to secure its IT systems and this failure directly caused the plaintiff’s damages related to improper disclosure of health information.

  • Bailment: The second cause of action is Bailment. A “bailment” arises when personal property is delivered to another for some particular purpose with an express or implied contract to redeliver when the purpose has been fulfilled.

    In other words, “I’m giving you my stuff with the expectation that I’ll get it back in the same condition.”

    The Complaint alleges that the plaintiffs provided Premera with their personal information with the understanding that Premera would adequately safeguard it.  Premera breached its bailment by failing to protect the information which resulted in the data breach.

  • Breach of Contract: The third cause of action is breach of contract. My first question concerning this claim is: “Did Premera actually state in its beneficiary agreements that it would keep all data secure?”

    Based on the allegations in the Complaint, the answer appears to be no.

    However, the Complaint alleges that Premera’s Notice of Privacy Practices (NPP) states that Premera must take measures to protect each beneficiary’s health information. Whether or not an NPP is actually a contract between a covered entity and individuals, this allegation should motivate health care entities to be careful in drafting their NPPs.

  • Washington State Data Breach Claim: In emphasizing the “no private right of action under HIPAA” mantra. Many entities fail to take understand state laws concerning data breaches.

    In the Complaint, the plaintiffs allege that Premera violated the Washington State data breach notification requirements of RCW 19.255.010. Unlike HIPAA, affected individuals may bring claims for violations of this statute.

    Among the requirements of RCW 19.255.010 is to disclose data breaches in the most “expedient” time possible and without “unreasonable delay.” The Complaint alleges that Premera took far too long to notify beneficiaries of the data breach.

Conclusion

In light of these claims (and others) in the Premera breach complaint, the warning for health care entities is clear: You can be sued by your customers for data breaches.

Although HIPAA may not provide for a private right of action, there are many other ways for plaintiffs to recover compensation for the failure to keep health information secure.

For more information about data breaches, please contact Casey Moriarty.

Failure to Patch Software Leads to $150K HIPAA Settlement

Anchorage Community Mental Health Services, Inc. (“ACMHS”) a nonprofit mental health provider in Alaska, has agreed to a $150,000 HIPAA settlement and 2 year Corrective Action Plan with HHS following a breach of 2,743 patient records due to malware.  According to the HHS press release:

OCR’s investigation revealed that ACMHS had adopted sample Security Rule policies and procedures in 2005, but these were not followed. Moreover, the security incident was the direct result of ACMHS failing to identify and address basic risks, such as not regularly updating their IT resources with available patches and running outdated, unsupported software.

According to the Resolution Agreement, OCR uncovered the following HIPAA violations:

  • ACMHS failed to conduct an accurate and thorough risk assessment.
  • ACMHS did not implement security measures sufficient to reduce the risks and vulnerabilities to its ePHI.
  • ACHMS’ security infrastructure did not appropriately guard against unauthorized access to ePHI that is transmitted over an electronic communications network.  Specifically, HHS noted that ACHMS failed to “ensure that firewalls were in place with threat identification monitoring of inbound and outbound traffic and that information technology resources were both supported and regularly updated with available patches.”

In addition to the $150,000 HIPAA Settlement, ACMHS will be under HHS’ microscope for the next two years.  The Corrective Action Plan requires ACMHS to implement the following changes:

  • Draft updated and adopt Security Policies and Procedures and submit to HHS within 60 days.
  • Distribute new Security Policies and Procedures to all workforce members and require the workforce members to sign a compliance certification.
  • Provide training on security awareness to all workforce members and annual training thereafter.
  • Perform an accurate and thorough risk assessment.
  • Inform HHS if a workforce member fails to adhere to the Security Policies and Procedures.
  • Provide annual reports to HHS.

ACMHS’ settlement provides three key takeaways for covered entities and business associates:

1) Patch & Update.  Like Community Health Systems, which reported a breach of 4.5 million patient records due to Chinese hackers targeting a heartbleed vulnerability, ACMHS is finding out the hard way the importance of software patching and updating.  Staying up to date on security patches and software updates is not an easy task, but an important one considering that hackers are exploiting these vulnerabilities.

2) Tailor the Security Policies and Procedures.  Simply having in place template Security Rule policies and procedures is insufficient to satisfy the requirements of the HIPAA Security Rule and to ultimately secure ePHI.  HIPAA Security policies need to be tailored for the actual information security infrastructure in place at the covered entity/business associate.  The Security Rule permits flexibility when choosing which tools to deploy to protect ePHI, but requires that the covered entity/business associate actually evaluate its infrastructure to make these decisions.

3) Security Risk Analysis.  Further, once the Security Policies and Procedures are in place they need to be evaluated, and the actual system needs to undergo a security risk assessment (suggestion to do this at least annually).  The process of drafting the Security Policies and Procedures as well as the security risk assessment will aid covered entities/business associates in identifying vulnerabilities, evaluating security options, and ultimately safeguarding their ePHI.  HHS has created a security risk assessment tool to help covered entities (not really business associate focused) in evaluating its security compliance.

For more information about the HIPAA Security Rule or if you need assistance in creating your HIPAA Security Policies and Procedures please contact Elana Zana.

HHS Security Risk Assessment Tool Webinar

The Office of the National Coordinator announced today that it will host a webinar to discuss its Security Risk Assessment Tool.

This webinar is designed to review the current state of the tool, discuss some of the known issues and ONC’s plan to address those identified issues, and answer questions from users across the country.

The webinar will be on April 29th at 2:00 PM Eastern (11:00 AM Pacific).  To register click here.

To learn more about the Security Risk Assessment Tool and using it for HIPAA and meaningful use compliance read our previous article here.