No Laughing Matter — Why the Cartoon Network Case Points Out a Shortsighted Flaw in Defining Personally Identifiable Information Narrowly

cartoon networkIn the past, I have blogged about de-identification. Simply put, de-identification is the process of rendering personally identifiable data unidentifiable and thus enabling the use of the information for various purposes free from regulation. A recent court case made me think to write again not just on the value of anonymizing data prior to sale or release, but also of the need for older privacy laws to be revisited in view of the Internet and expansive databases filled with personally identifiable Information.

In Ellis v. Cartoon Network(1:14-cv-00484, U.S. District Court for the Northern District of Georgia) the plaintiffs asserted a class action suit against the Turner cable TV channel, Cartoon Network. Lead plaintiff Mark Ellis alleged that when he downloaded the Cartoon Network app (“App”) on his Android device, he never agreed to the disclosure of his personally identifiable information and that each time he viewed a Cartoon Network clip using the App, that information was sent directly to a third party company called Bango that allegedly used the information for direct marketing purposes. The information being sent to Bango comprised, amongst other things, the identification numbers for App user’s devices, specifically the Android ID number. Bango would allegedly take the data from the App, build a larger consumer profile using outside data in its possession and linked via the Android ID and then sell the enhanced, identifiable consumer information for targeted marketing purposes.

»» Read More

Posted by Scot Ganow
Data Security
October 28, 2014

Getting Familiar with the HIPAA Data Breach Rule (Part 1)

breachWe recently hosted representatives from the Office of Civil Rights (“OCR”) in both Dayton and Cincinnati. During their visits, they provided attendees insight into the forthcoming HIPAA audits as well as shed some light on what the OCR expects to see when it comes to investigating data breaches. We will be writing a series of blogs on various HIPAA topics in the coming months. And, with the rece  nt rash of high profile data breaches, we decided to start with a quick primer of the basics of data breach under HIPAA. The HIPAA Breach Notification Rule (45 C.F.R. §164.414) requires covered entities and business associates to implement policies and procedure to address the timely reporting of breaches. Oh sure, “data breach is data breach,” you might say. But, as with any data breach, you first have to determine if you even have a “breach,” at least as defined by the law. HIPAA is no different.

So, let’s start with what a data breach is under HIPAA. Generally, a “breach” is an impermissible use or disclosure under the HIPAA Privacy Rule (“Privacy Rule”) that compromises the security or privacy of the PHI (“PHI”).  Any impermissible use or disclosure of PHI is presumed to be a breach and requires some form of notice to be given unless the covered entity or business associate involved demonstrates that there is “a low probability that the PHI has been compromised.” The OCR has branded this low probability as “LoProCo.” It is also important to note that this breach rule applies to “unsecured PHI,” meaning PHI that has not been encrypted or otherwise rendered de-identified.

A breach is presumed to have occurred, unless the covered entity or business associate can make a LoProCo assessment by providing a risk assessment, which accounts for the following factors:

  1. The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification;
  2. The unauthorized person who used the PHI or to whom the disclosure was made;
  3. Whether the PHI was actually acquired or viewed; and
  4. The extent to which the risk has been mitigated for the PHI.

Covered entities and business associates, where applicable, have discretion to provide the required breach notifications following an impermissible use or disclosure without performing a risk assessment to determine the probability that the PHI has been compromised. As with any law, you might expect some exceptions to what is defined as a “breach” and whether notice is required.

  1. Unintentional PHI access, acquisition, or use.   Unintentional access, collection or use of PHI by workforce member or person acting under the authority of a covered entity or business associate does not constitute a breach if such acquisition, access, or use was made in good faith and within the scope of authority. The information cannot be further used or disclosed in a manner not permitted by the Privacy Rule for this exception to apply.
  2. Inadvertent disclosure. An Inadvertent PHI disclosure is one made by a person authorized to access PHI at a covered entity or business associate to another person authorized to access PHI at the covered entity or business associate. Or, maybe the information is provided to another organized health care arrangement in which the covered entity participates. The information cannot be further used or disclosed in a manner not permitted by the Privacy Rule for this exception to apply.
  3. Good faith that information not retained. An impermissible disclosure is also not a breach if the covered entity or business associate has a good faith belief that the unauthorized person to whom the impermissible disclosure was made would not have been able to retain the information.

Again, this is just a primer on the basics of data breach under HIPAA. As always, each situation is different, and the time is now to review how your organization is prepared to assess and address a data breach. In truth, this process never stops, it just evolves. As we have said many times before, it is not IF you have a breach or incident, but WHEN. In our next blog, we will discuss the notice requirements pertaining to a breach under HIPAA.

Posted by Scot Ganow
Data Security
October 6, 2014

The Internet of Things: Why Administrative Safeguards and People Remain a Critical Focus, Even Up There in the Cloud (Pt.4)

In our final installment on the Cloud, Tim Rettig and Scot Ganow bring it all together in discussing the importance of security in depth and how, even in the Cloud, the need for solid administrative safeguards remain. Critical elements discussed include policies, procedures, contracts and training based on all of these to manage the top security risk for any company:  people.

Posted by Scot Ganow
Data Security
October 2, 2014

Next Page »