HIPAA Omnibus: Determining BreachesExpert Offers Compliance Pointers
The new HIPAA Omnibus Rule includes the final regulations on breach notification. While some organizations may not need to change their incident response plans to comply with the final breach notification rule, many others have been missing the boat when it comes to identifying a breach of protected health information. This final rule is less a change than a clarification of the Department of Health and Human Services' - and Congress' - original intent.
See Also: What is next-generation AML?
HHS notes in the rule preamble that some organizations have set a much higher threshold than HHS intended for an incident being a breach. To make this point explicit, the final rule states that "an acquisition, access, use or disclosure of [unsecured] protected health information in a manner not permitted under [the HIPAA Privacy Rule] is presumed to be a breach. ..." That presumption should be the starting point for responding to an incident. Only if an organization performs the rule's specified risk assessment and "demonstrates that there is a low probability that the protected health information has been compromised" is the organization off the hook for breach notification (although the incident may still be a HIPAA violation to be dealt with).
The risk assessment is performed to rule out the probability that an incident is a breach.
Fortunately, to avoid "inconsistent interpretations and results," HHS, in the final version of the breach notification rule, replaces assessing risk to individuals with assessing risk to data, i.e., PHI. This language is more consistent with risk assessment practices that HIPAA covered entities and business associates should be following for HIPAA Security Rule compliance.
It's important to note that risk assessments estimate the potential for harm or an adverse impact. We don't wait to see if lost or stolen data - e.g., unencrypted medical records or Social Security numbers on a laptop - are misused before declaring a breach. In fact, no identifiable harm may ever come from a breach - but it is still a breach.
Let's say that a worker's laptop with unencrypted PHI goes missing. This is most likely a breach, and that assumption should be the starting point for investigating the incident. The risk assessment is performed to rule out the probability that the incident is a breach. Based on the four factors moved from the interim rule's preamble to the final rule itself, here's a scenario where the incident might not be a breach.
- The PHI consists of patient names only, and the organization is a general medical practice. But if seemingly benign addresses and telephone numbers were included, some patients (e.g., estranged spouses) who wanted to keep this information private may be exposed. And if the organization offered only specialty services, such as oncology or obstetrics, clinical information about each patient could be inferred.
- The missing laptop is found in the worker's building. Co-workers are subject to the same policies, training and sanctions, so the PHI may be safe. But anyone in the building, a worker or an outsider, could have had access to the laptop.
- The missing laptop is returned to the worker without any evidence of tampering. But someone in the building could have accessed the PHI. Password crackers are easy to use. Someone could have read, and even copied, the PHI, for a variety of unauthorized purposes.
- The organization uses forensics tools and determines that no files were opened since the worker last used the laptop.
Each step of the above risk assessment scenario presents the most favorable outcome in terms of risk. But real-life lost laptop incidents are apt to carry some degree of risk that the PHI could be compromised.
Borten is president and founder of security and privacy consulting firm, The Marblehead Group. Before launching the firm in 1999, she led the enterprisewide security program at Massachusetts General Hospital in Boston and established the first information security program at Beth Israel Deaconess Medical Center and its parent organization, CareGroup, as its chief information security officer.