Peeling Back BCBS’s $1.5 Million HIPAA Settlement Onion

by | Mar 20, 2012 | Data Breach Laws, Government Enforcement

As many of our readers have already heard, on March 13, 2012 HHS announced that Blue Cross Blue Shield of Tennessee entered into a Resolution Agreement for $1.5 Million Dollars to settle potential violations of HIPAA. You can access a copy of the Resolution Agreement here.

I find this new case both instructive and frightening, but one has to peel back the layers of this HIPAA-onion to really understand why the Resolution Agreement between BCBS of Tennessee (BCBSOTenn) and HHS/OCR creates an even greater nerve-racking precedent than may be immediately apparent.

First, it must be noted that OCR initiated its investigation of the Breach incident and BCBSOTenn only after BCBSOTenn submitted its HITECH Breach Report “in compliance with” 45 CFR §164.408.  Therefore, HHS/OCR appears to acknowledge that BCBOTenn’s reporting of the Breach was timely, proper and otherwise in compliance with the Breach Notification Rule.  And, while BCBSOTenn did not seem to get much reprieve here for its diligent Breach reporting, it’s important to point out that just because a covered entity experiences a Breach does not in and of itself mean that the covered entity has violated the HIPAA Privacy or Security Rule.  A covered entity must actually fall short of or be non-compliant with a HIPAA Privacy Rule standard or Security Rule standard before an actual violation can be found.

So, at least hypothetically, a covered entity could still be in full compliance with the HIPAA Privacy and Security Rules, even if it experienced a Breach involving or potentially compromising PHI.

In such a situation, as long as the covered entity properly and timely reports the Breach as required under the HITECH Breach Rule, and has a fully compliant, current and effective HIPAA compliance program implemented, then the covered entity should be able to assert that there were no violations of HIPAA or HITECH to give rise to HHS/OCR assessing penalties against it.  However, at least for BCBSOTenn, apparently the costs and burden of going through an investigation to prove that the Breach was not due to an underlying lapse its HIPAA compliance program was not worth it, at least not $1.5 Million.

What may be most chilling from a compliance perspective here, however, is that the Breach incident itself was allegedly caused by an intervening criminal act, and that BCBSOTenn had presumably paid Eastgate to provide security services to safeguard the data closet where the video and audio recordings were being temporarily stored until their scheduled relocation at the end of November 2009;  and, indeed, it seems that Eastgate did have a lot of appropriate physical safeguards in place, including biometric and keycard scan security with a magnetic lock, an additional door with a keyed lock, and basic security services.

So, if BCBSOTenn contracted, paid for and relied on Eastgate to provide security services, one would think that it would be reasonable for BCBSOTenn to believe that it had taken appropriate steps to attempt to safeguard the e-PHI while it was temporarily stored at the data closet.  What is not discussed in the Resolution Agreement, however, but would be interesting to know is whether BCBSOTenn’s contract with Eastgate included HIPAA BAA-type language to ensure that Eastgate was aware of the sensitive nature of what they were securing (i.e., e-PHI), and to contractually obligate Eastgate to have in place at least minimum administrative, technical and physical safeguards with regard to how it ensured the security of the data closet.  This illustrates a good lesson, which is while a security vendor or a building manager may not technically be a HIPAA BA, as historically defined by HHS (because such third parties are not required to access PHI to perform their function on behalf of the covered entity), in any instance where a covered entity relies on a third party to ensure the security of its PHI or e-PHI, including software vendors, data warehouses, cloud providers and other similar types of third parties, it is important to have such third party contractually agree to have in place HIPAA BA-type safeguards, and to agree to be responsible for any damages that may arise from a Breach that is due to their own negligence. In this case, Eastgate did not respond to evaluate an unresponsive gate for the entire weekend. While it is not clear whether this may or may not have been negligent on the part of Eastgate, hopefully BCBSOTenn had provisions in its agreement with Eastgate that required insurance coverage for such incidents and will allow BCBSOTenn to also potentially make a claim for indemnification if there was indeed fault on the part of Eastgate.

Finally, despite the fact that the theft of the e-PHI was the event that precipitated HHS/OCR to conduct an investigation here, it almost seems that its settlement with BCBSOTenn had less to do with the actual Breach incident itself and more to do with what HHS/OCR may have believed could be lacking with BCBSOTenn’s general HIPAA compliance program.  In fact, the corrective action plan (CAP) in the Resolution Agreement does not include any requirement to take any actions, like encryption, with regard to similarly stored data devices.  Instead, the CAP focuses on HHS/OCR having the opportunity to review BCBSOTenn’s written policies for conducting a risk assessment, conducting a risk management plan, addressing facility access controls and a facility security plan, and addressing physical safeguards governing the storage of e-PHI.  The CAP also requires such policies to be revised, IF HHS/OCR suggest “material changes” to the policies, and to be distributed to all BCBSOTenn workforce, who must then sign a certification of receipt, and be retrained. Now, while that is all well and good, I wonder about HHS/OCR focusing on BCBSOTenn workforce when wasn’t it the employees of Eastgate who were the ones that did not respond to the lapse in security?  At least in this instance, then, the real security gap seemed to be with BCBSOTenn’s contracted security vendor’s workforce, not its own.

This case certainly raises questions and concerns with investigation and enforcement processes, but also offers some instruction.  First, it is important for covered entities to review their contracts with third parties that may have access to PHI, and most certainly if such third party may be directly or indirectly responsible for ensuring the security of its PHI.  Covered entities should include clear language regarding allocation of responsibility for security, and severe repercussions, including potential indemnity, if the vendor falls short. Contracts with technology vendors, cloud providers, facility security providers, and the like are all potential areas where security weaknesses and gaps may exist.

Finally, while the outcome of the BCBSOTenn situation may tempt many to be more hesitant with reporting Breaches to HHS, that is not advisable.  Not reporting a Breach incident when it is legally required to be reported under the law could just lead to additional potential penalties for violations of the HITECH Breach Rule.  Thus, while Breach reporting clearly can lead to an OCR investigation, as it did here, the best defense may be for covered entities and business associates to ensure that their HIPAA Policies and Procedures are well-developed, updated, and implemented so that they can all be handed to HHS/OCR as proof of full HIPAA compliance, despite any Breach incident having occurred.

Share this:

If you are not a subscriber to our backend Legal HIE compliance library, download our Table of Contents here to check out all of the tools, checklists, whitepapers, sample policies we make available to our members to help their organizations comply with Information Blocking, HIPAA, 42 CFR Part 2, Data Breaches and more. Ready to subscribe now? Click here to review our subscription options.

Archives