Breach Reporting Requirements

The Department of Health and Human Services (HHS) released on Wednesday, August 19, 2009, its interim final rule for “breach notification,” as required under the Health Information Technology for Economic and Clinical Health (HITECH) Act, passed as part of the American Recovery and Reinvestment Act of 2009 (ARRA) (“HHS Breach Rule”).  HHS was two-days late with the issuance of the final rule for breach notification.  The interim final rule requires HIPAA covered entities to notify individuals—and, in some cases, the HHS Secretary and the news media—when “unsecured protected health information” is breached or compromised.  The interim final rule is scheduled for publication in the Federal Register on Monday, August 24, 2009.  The rule will be effective thirty days after publication in the Federal Register (approximately September 23, 2009); comments on the rule are due to the HHS Office of Civil Rights within sixty days of the rule’s publication (approximately October 23, 2009).  However, HHS In the comments to the new Breach Reporting Rules, states that HHS “will use [its] enforcement discretion to not impose sanctions for failure to provide the required notifications for breaches that are discovered before 180 calendar days from the publication [of the HHS regulations],”  which will be the middle of February 2010.

Personal Health Records and the FTC Security Breach Rule

Also on August 17th, 2009, the FTC, as required by ARRA, issued the final guidance regarding security breach notification requirements for entities that collect personal health information and/or vendors of personal health records for purposes of a consumer directed health record.  The FTC released the proposed regulations entitled the “Health Breach Notification Rule” on April 16, 2009.  Unlike, Electronic Health Records (EHRs), Personal Health Records (PHRs) are not covered by HIPAA, however, PHRs are covered by some states’ security breach notification rules (e.g. California).  The FTC’s rules expands the scope of entities that must take certain actions in the event of a PHR security breach, but the rule does not apply to HIPAA Covered Entities or Business Associates (with one exception discusse below).  The FTC regulations will apply to “breaches of security” that occur on or after September 18, 2009, if the breach involves information contained in or related to PHRs.  While the interim final rule for “breach notification” issued by HHS will apply to HIPAA Covered Entities and Business Associates.  Unlike an EHR, PHR’s are “electronic record of identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” (FTC Final Rule (Guidance) p. 27).

The FTC further clarified the definition of a PHR:

The Commission emphasizes that PHRs are managed, shared, and controlled “by or primarily for the individual.” See, e.g., AIA at 2; ACLI; Molina Healthcare at 2-3; National Association of Mutual Insurance Companies (“NAMIC”) at 3-4. Thus, they do not include the kinds of records managed by or primarily for commercial enterprises, such as life insurance companies that maintain such records for their own business purposes.

PHI and HHS’ Security Breach Rule

Interestingly the preamble to the HHS breach rule clarifies that in some instances a HIPAA business associate could theoretically covered by the FTC and HHS security breach notification requirements-  in those limited cases where an entity may be subject to both HHS’ and the FTC’s breach notification rules, such as a vendor that offers PHRs to customers of a HIPAA covered entity as a business associate and also offers PHRs directly to the public, HHS and FTC have apparently been harmonized by including the same (or similar requirements). (HHS Breach Notification Rule p. 14).

Similar to the FTC  breach notification regulations for PHR vendors, the regulations developed by the HHS Office for Civil Rights (OCR) requires health care providers and other HIPAA covered entities to promptly notify affected individuals of a breach, as well as the HHS Secretary and the media in cases where a breach affects more than 500 individuals.  Breaches affecting fewer than 500 individuals will be reported to the HHS Secretary on an annual basis. The regulations also require business associates of covered entities to notify the covered entity of breaches at or by the business associate.

“This new federal law ensures that covered entities and business associates are accountable to the Department and to individuals for proper safeguarding of the private information entrusted to their care.  These protections will be a cornerstone of maintaining consumer trust as we move forward with meaningful use of electronic health records and electronic exchange of health information,” said Robinsue Frohboese, Acting Director and Principal Deputy Director of OCR.

(FTC Final Rule (Guidance) p. 27).

Acceptable Encryption Methods and the Effect Thereon of the Data’s Current State

The commentary to Breach Notification rules include further details regarding the distinctions between data at rest and data in motion:

• “Data in Motion” includes data that is moving through a network, including wireless transmission, whether by e-mail or structured electronic interchange, while “data at rest” includes data that resides in databases, file systems, flash drives, memory, and any other structured storage method;
• “Data in Use” includes data in the process of being created, retrieved, updated, or deleted, and “data disposed” includes discarded paper records or recycled electronic media;
• “Data at Rest” includes data that resides in databases, file systems, flash drives, memory, and any other structured storage method; and
• “Data Disposed” includes discarded paper records or recycled electronic media.

While these categories are not new to computer security practitioners they represent a much more advanced approach as compared against earlier HIPAA privacy and security guidance. (Guidance at 12).  The Guidance notes that HHS consulted the NIST when identifying appropriate safeguards.  The reader is also directed to review the NIST Special Publication 800-66-Revision1 “An Introductory Resource Guide for Implementing the HIPAA Security Rule“.

Encryption is one of the core methods to render PHI unreadable; however encryption encompasses domains such as cryptology, number theory, and crypto analysis for even the most well versed security expert understanding how to encrypt information properly is complex.  HHS solves this problem by relying on NIST.  PHI must be encrypted using a NIST approved algorithm and procedure– to be considered unreadable.  Electronic PHI is encrypted when “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304) and key to decrypt the PHI has not been breached.  Encryption identified by NIST and judged to meet this standard NIST’s encryption standards is acceptable to render PHI unreadable. (Guidance at 16).  Current acceptable encryption methods include:

• For data at rest the reader those methods contained within NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Device; and
• For data in motion those methods contained within the Federal Information Processing Standards (FIPS) 140-2 are acceptable. These methods are explained in detail in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113,Guide to SSL VPNs, and others which are FIPS 140-2 validated. (Guidance at 17).

The commentary notes that:

[C]overed entities and business associates may continue to create limited data sets or de-identify protected health information through redaction if the removal of identifiers results in the information satisfying the criteria of 45 CFR 164.514(e)(2) or 164.514(b), respectively. Further, a loss or theft of information that has been redacted appropriately may not require notification under these rules either because the information is not protected health information (as in the case of de-identified information) or because the unredacted information does not compromise the security or privacy of the information.

Finally HHS notes that the encryption/ destruction guidance will be updated annually.  The press release notes-

To determine when information is “unsecured” and notification is required by the HHS and FTC rules, HHS is also issuing in the same document as the regulations an update to its guidance specifying encryption and destruction as the technologies and methodologies that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals.  Entities subject to the HHS and FTC regulations that secure health information as specified by the guidance through encryption or destruction are relieved from having to notify in the event of a breach of such information.  This guidance will be updated annually.

An excellent demonstration of the Advanced Encryption Standard (AES) — one of the few FIPS approved algorithms to render PHI unreadable and/or encrypted for purposes of the security breach safe harbor under both the FTC and HHS rules is avaliable at http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf.

Destruction is also an acceptable method of rendering PHI unreadable, acceptable methods for destroying PHI at this time:

• Paper, film, or other hard copy media be shredded or destroyed such that the PHI cannot be read or otherwise reconstructed; and
• Electronic media must be cleared, purged, or destroyed consistent with NIST Special Publication 800-88,Guidelines for Media Sanitization, such that the PHI cannot be retrieved. (Guidance at 17).

HHS draws an interesting distinction between encryption and other access controls:

While we believe access controls may render information inaccessible to unauthorized individuals, we do not believe that access controls meet the statutory standard of rendering protected health information unusable, unreadable, or indecipherable to unauthorized individuals. If access controls are compromised, the underlying information may still be usable, readable, or decipherable to an unauthorized individual, and thus, constitute unsecured protected health information for which breach notification is required.

Accordingly, HHS believes strong access controls are required however HHS believes that a review of potential safeguards is beyond the scope of the this guidance which primarily details methods of rendering PHI unreadable.

Following the same line of reasoning HHS rejected redaction of PHI as a method of rendering PHI unreadable.  The preambles states that “redaction is not a standardized methodology with proven capabilities to destroy or render the underlying information unusable, unreadable or indecipherable, we do not believe that redaction is an accepted alternative method to secure paper-based protected health information.”  However the physical destruction of paper is a method rendering PHI unreadable.  This again is a rather interesting distinction considering that electronic documents, for example PDFs, can be redacted such that the information cannot be recovered.

The reader should note that covered entities and business associates must keep encryption keys on a separate device from the data that they encrypt or decrypt to ensure the keys are not compromised.

Harm or Risk Based Threshold

HHS confirmed that the statutory language and the new breach regulations includes a harm threshold and the definition that “compromises the security or privacy of the protected health information” means “poses a significant risk of financial, reputational, or other harm to the individual.”  This position is consistent with some State breach notification laws, as well as other existing obligations on Federal agencies (some of which also must comply with these rules as HIPAA covered entities) pursuant to OMB Memorandum M-07-16 (available at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf) to have in place breach notification policies for PII that take into account the risk of harm caused by the breach.  Thus, to determine if an impermissible use or disclosure of PHI constitutes a breach, covered entities and business associates will need to perform a risk assessment to determine if a significant risk of harm to the individual as a result of the impermissible use or disclosure. In performing the risk assessment, covered entities and business associates should consider a number of factors.  Five factors that should be considered to assess the likely risk of harm:

• Nature of the Data Elements Breached. The nature of the data elements compromised is a key factor to consider in determining when and how notification should be provided to affected individuals.41 It is difficult to characterize data elements as creating a low, moderate, or high risk simply based on the type of data because the sensitivity of the data element is contextual. A name in one context may be less sensitive than in another context.42 In assessing the levels of risk and harm, consider the data element(s) in light of their context and the broad range of potential harms flowing from their disclosure to unauthorized individuals.
• Number of Individuals Affected. The magnitude of the number of affected individuals may dictate the method(s) you choose for providing notification, but should not be the determining factor for whether an agency should provide notification.
• Likelihood the Information is Accessible and Usable. Upon learning of a breach, agencies should assess the likelihood personally identifiable information will be or has been used by unauthorized individuals. An increased risk that the information will be used by unauthorized individuals should influence the agency’s decision to provide notification.

(See OMB Memorandum M-07-16, page 14)(avaliable at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf).

HHS notes that the fact the information has been lost or stolen does not necessarily mean it has been or can be accessed by unauthorized individuals.  A June 2007 GAO Report entitled “PERSONAL INFORMATION- Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown” (Dated June 2007) expands upon this rather important point.  The GAO report reviewed the 24 largest breaches reported in the media from January 2000 through June 2005 finding that:

1. Only in three instances were there any evidence of resulting fraud on existing accounts and only one instance of the three identified cases did the GAO find evidence of unauthorized creation of new accounts;
2. For 18 of the breaches, no clear evidence had been uncovered linking them to identity theft; and
3. In the remaining two cases there was not sufficient information to make a determination.

Practical Steps in the Event of a Breach

In the comments to the new Breach Reporting Rules, HHS provides a basic overview of the steps to follow in order to determine whether the entity has breach reporting obligations.  The recommended steps are as follows:

Step 1 – Determine whether the disclosure or use of PHI was impermissible under the HIPAA Privacy Rule.

Step 2 – Determine whether the PHI was “secured” or “unsecured,” and whether the impermissible use or disclosure of PHI compromises the security or privacy of such PHI, and document its process and determination.  The use or disclosure would be impermissible if it poses a “significant risk of financial, reputational, or other harm to the individual.”

Step 3 -   Determine whether the use or disclosure falls under one of the exceptions to the definition of a “breach.”  The exceptions to the definition of a “breach” are: (i) any unintentional access or use of PHI by a Covered Entity’s or Business Associate’s workforce or person acting under the authority thereof, if such access was in good faith, within that person’s scope of authority, and did not result in further impermissible use or disclosure of the PHI; (ii) any inadvertent disclosure by a person who is authorized to have access to such PHI to another authorized person at the same Covered Entity or Business Associate, or organized health care arrangement in which the Covered Entity participates, and the PHI disclosed is not further used or disclosed in an impermissible manner; and (iii) disclosure of PHI where the Covered Entity or Business Associate has a good faith believe that the unauthorized person who received the PHI would not reasonably have been able to retain such PHI.

If the breach poses a significant risk to the individual whose PHI was disclosed, and the disclosure does not fall under one of the enumerated exceptions to the definition of a “breach,” the entity must take the following step:

Step 4 – Provide appropriate notice of the breach in accordance with the Breach Reporting Rules.

Regardless of whether a breach is in violation of the Privacy Rule or Security Rule and raises reporting obligations under the Breach Reporting Rules, the entity may have reporting obligations under state security breach reporting laws that are not preempted by the Privacy Rule or Security Rule.  Therefore, it would be prudent for the entity to take the following additional step:

Step 5 – Determine whether the breach raises any additional reporting obligations under applicable state security breach reporting laws.

          

Related posts:

1. Business Associate and Covered Entity HIPAA Compliance — Auditing Questions and NIST 800-53 Security Controls. This article discusses techniques for implementing the updated requirements of...
2. HHS Tranfers Enforcement of the HIPAA Security Rule to OCR (Office of Civil Rights) It appears HHS has taken this critique to heart. HHS...
3. Fear Mongering or Legitimate Criticism — “HHS guts health-care breach notification law, groups warn” I am a little unclear as to why privacy advocates...