HIPAA Rules and Procedures in the Event of a Data Breach, Part One
As discussed in my prior post, recent massive data breaches at major retailers and health insurance providers paint a bleak picture of modern data and emphasize the importance of strong security safeguards and plans for handling suspected security breaches for electronic protected health information (“ePHI”). In the healthcare context, a security breach of a covered entity or a Business Associate’s (BA) data security system triggers the Security Rule and can trigger certain breach notification requirements under Health Insurance Portability and Accountability Act (“HIPAA”) and Health Information Technology for Economic and Clinical Health Act (“HITECH”). This post will discuss the investigation needed to determine whether a breach has taken place, while the next post will discuss the necessary notifications in the event of a breach.
Determining Whether an Actionable Breach Has Taken Place
HIPAA defines a security breach as “the acquisition, access, use, or disclosure of protected health information in a manner not permitted…which compromises the security or privacy of the protected health information.” Pursuant to this definition, the first thing a CE must do is investigate the breach and determine whether unsecured PHI has been compromised. Data is compromised when there is “a significant risk of financial, reputational, or other harm to the individual.”
PHI is unsecured when the PHI “is not … unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary…” Thus, PHI is secure when the data is either encrypted to certain technology standards or the ePHI has been destroyed, which means breach notification is not required. However, encrypted PHI is only secure if the key to decrypt the data is secure and remains confidential.
If ePHI is not encrypted or the decryption key is no longer secure, the data is not secure and data breach will trigger breach notification.
Thus, the best compliance practice is to encrypt all ePHI, whenever practicable, to take advantage of this regulatory safe harbor. Because breach notification can cause irreparable harm to an entity’s reputation and financial status, encryption is an important means to mitigate damages and risks of a data security breach.
In the case of a suspected security breach, covered entities need to take steps to thoroughly investigate the incident, determine if a security breach of unsecured PHI occurred, and determine the extent of the security breach or leak of information and the amount of PHI breached before the covered entity can take steps to stop the leak of PHI and reduce the damage caused by the security breach.
In 2013, the Omnibus Final Rule (“Final Rule”) released by the Department of Health and Human Services (“HHS”) redefined what was considered a security breach. Now, a security breach is presumed unless the entity can demonstrate that there is a low probability that any unsecured ePHI has been compromised.
The only way to show a low probability of compromise is by conducting a risk assessment to consider at least four significant factors:
(i) The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification;
(ii) The unauthorized person who used the protected health information or to whom the disclosure was made;
(iii) Whether the protected health information was actually acquired or viewed; and
(iv) The extent to which the risk to the protected health information has been mitigated.
If a covered entity cannot identify a low probability that unsecured ePHI has been compromised, breach notification is triggered.
Come back Thursday for a discussion of breach notification provisions that apply in the event of a compromise of unsecured ePHI.
 45 CFR § 164.402
 45 CFR § 164.402(1)(i)
 45 CFR § 164.402
 HHS guidance on the processes and standards for securing ePHI can be found on the HHS website: http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html (last accessed April 21, 2015)
 45 CFR § 164.402(2)