No Secrets: Reporting Obligations of HIPAA Business Associates
Once upon a time, privacy and information security were an afterthought during contract negotiations. But breach notification has fundamentally changed the process, causing organizations to become increasingly concerned with their service providers’ privacy and security practices. Breach reporting time periods and breach indemnification costs can be the most hotly contested provisions in a contract negotiation. This article discusses the multitude of privacy and security reporting obligations under HIPAA and state law and identifies potential contracting strategies to reconcile them.
Because of HIPAA’s history, there are not one but actually three reporting obligations between business associates and covered entities: (1) breaches of unsecured protected health information; (2) impermissible uses and disclosures that do not rise to the level of a “breach”; and (3) security incidents. It is important to understand the distinctions between each and where there is latitude in the contracting process.
Breaches of Unsecured Protected Health Information
The newest of the reporting requirements is with respect to “breaches of unsecured protected health information.” This is the most serious type of incident because a business associate must report a breach of unsecured protected health information up the chain (e.g., to the covered entity or higher level business associate in the contracting chain), and the covered entity ultimately must report the breach to affected individuals, the U.S. Department of Health and Human Services (“HHS”), and the media (if more than 500 individuals were affected in a single state or jurisdiction). Breaches often lead to substantial breach notification costs (which may include credit monitoring), government investigations (and the potential for financial penalties or settlement), reputational harm for all involved, and heightened risk of a class action.
An impermissible use or disclosure of protected health information is presumed to be a “breach” unless: (1) the protected health information was secured through appropriate encryption or destruction; (2) one of three statutory exceptions apply; or (3) the covered entity or business associate conducts a breach risk assessment and determines that there is a “low probability of compromise” of the information. The three statutory exceptions are narrow, applying to certain unintentional acquisitions of protected health information by members of the workforce and other persons acting under the authority of the organization (e.g., an employee accidentally access the wrong record when doing his or her work), to certain inadvertent disclosures where the unintended recipient was also authorized to access the information (e.g., a record is sent to the wrong doctor, but the doctor was authorized to access the record anyway), or to certain disclosures where the organization has a good faith belief that the unintended recipient could not retain the information (e.g., a misdirected letter is returned, unopened, as undeliverable).
The more important exception is where a breach risk assessment determines a low probability of compromise. The risk assessment must at a minimum consider four factors: (1) the nature and extent of the protected health information involved (e.g., is it readily identifiable and does it contain sensitive information); (2) the unintended recipient (e.g., is it a person or organization who has similar legal obligations to maintain the confidentiality of the information); (3) whether the information was actually accessed or viewed (e.g., was a device lost but then recovered, with forensic analysis concluding that the information was not accessed); and (4) the extent to which any mitigation is successful (e.g., the unintended recipient destroys the information without using or disclosing it). There remains confusion regarding what HHS considers a “compromise” and how it expects that the above four factors interplay. The regulatory preamble, though, suggests a high bar for applying these four factors and determining a low probability of compromise.
If an impermissible use or disclosure of protected health information does not fall within an exception, then it is a “breach of unsecured protected health information” and the business associate must report it to the covered entity (or the higher business associate in the contracting chain) without unreasonable delay, and in no case later than 60 calendar days after discovery. HIPAA permits a reporting delay when requested by law enforcement. The notification must include certain content to the extent available, including: (1) the identify of individuals affected; (2) a brief description of what happened, including the dates of breach and discovery; (3) a description of the types of protected health information involved; (4) any steps that individuals should take in response (e.g., check credit reports); (5) a description of what the business associate is doing to investigate the breach, mitigate harm, and protect against further breaches; and (6) contact information for the business associate.
Other Impermissible Uses and Disclosures
Even before HIPAA required notification of breaches of unsecured protected health information, the HIPAA Privacy Rule has always required business associate agreements to require the business associate to report all impermissible uses and disclosures of protected health information. The HIPAA regulations do not include any timing or content requirements for impermissible uses and disclosures that do not rise to the level of a breach. Rather, the timing and content of reporting is entirely at the discretion of the parties.
Security Incidents
The third type of report is a security incident, which is defined as “the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system.” The HIPAA Security Rule has always required business associate agreements to require the business associate to report any security incidents. The regulations do not specify timing and content requirements; rather these are entirely at the discretion of the parties.
In some instances, a security incident qualifies as a breach of unsecured protected health information. In other instances, such as destruction of information, it would not qualify or give rise to a breach because there is no impermissible use or disclosure of protected health information.
Contracting Options
Once a business associate understands its three distinct reporting obligations under HIPAA, it should consider how it will operationalize them and develop a corresponding contracting strategy. One option is to treat all impermissible uses and disclosures and security incidents as “breaches of unsecured protected health information,” in which case no breach risk assessment is ever necessary but all incidents must be reported within a certain time (without unreasonable delay and in no case later than 60 days after discovery, or shorter if required by the contract) and with all of the elements of a formal breach notification. The second option is to informally report all impermissible uses and disclosures and security incidents, conduct a breach risk assessment, and provide more detailed notification for incidents that rise to the level of a “breach.”
Each option has its advantages and drawbacks. Option 2 is advantageous for the business associate in that it allows more limited reporting for less serious incidents that do not rise to the level of a breach. Covered entities, however, may be unwilling to give this level of discretion to the business associate and instead insist on formal breach notification for all instances. Accordingly, Option 1 may be lead to easier contract negotiations.
Whether the business associate will be able to push a particular option will depend largely on how much leverage it has during the contract negotiation. But business associates should be sensitive to what they can actually operationalize and avoid agreeing to unrealistic terms, even when they have limited leverage. For example, a covered entity may insist on a five-day reporting period, or even a 24-hour reporting period (or, worst case, a one hour reporting period). Here, a tiered reporting strategy is critical. It may be possible to provide an initial, informal notification within a very short reporting period. This initial notice will put the covered entity at ease that they will not first learn of an incident 60 days after the business associate’s discovery. But it is far more challenging to provide full breach notification, with the six elements described above, within such a short reporting period.
The issue of “agency” may become a critical issue in negotiating reporting requirements. If the covered entity controls the manner in which the business associate’s work is performed (e.g., it can provide interim instructions above and beyond the contractual terms), then the covered entity will be deemed to know of a breach as soon as the business associate discovers the breach. In such cases where the business associate is considered an “agent” of the covered entity (rather than an independent contractor), the covered entity’s requirements to notify individuals, HHS, and the media begins as soon as the business associate discovers the incident. Accordingly, the greater the covered entity’s control over the manner in which the business associate works, the shorter the reporting time period the covered entity may insist upon.
Additionally, business associates should consider how they will address the extremely broad definition of “security incident,” which encompasses mere attempts (regardless of whether successful). The state of the world is such that a business associate may experience thousands of failed attempts at unauthorized access or interruption of services each day, and it may be unrealistic to log and report each attempt. Accordingly, one contracting strategy is to provide proactive notification, in the business associate agreement itself, of the regular occurrence of unsuccessful attempts. This may offer the best solution for both parties, as neither party may be interesting in knowing about such attempts. But some covered entities may be unwilling to take this approach because the HIPAA Security Rule requires the contract to require the business associate to report any “security incidents” (which is defined to include such attempts), and does not include a carve out or formal guidance suggesting that proactive notice will suffice.
Regardless of the reporting terms that the parties reach, the business associate should remain cognizant of state laws that may impose stricter requirements. These state laws are usually – but not always – limited to “computerized data” and “personal information” that creates a risk of identity theft. But the state law may require the business associate to report and breach of security “immediately” or may include a specific deadline.
In sum, business associates are subject to a variety of reporting requirements, including breaches of unsecured protected health information, impermissible uses and disclosures that do not rise to the level of a breach, security incidents, and state law requirements. It is important for business associates to understand the various obligations and develop policies and procedures that comply with all of them. The business associate then should try to conform its contacts to its operations, agreeing to provisions that satisfy the covered entity but are operationally realistic for the business associate. Otherwise, it is easy for the business associate to find itself agreeing to whatever terms the covered entity seeks, but ending up in a quagmire with hundreds of varying customer breach notification obligations that may not be achievable in practice.
Adam Greene is a partner in the Washington, D.C. office of Davis Wright Tremaine and co-chair of its Health Information Group. Adam primarily counsels health care providers, technology companies, and financial institutions on compliance with the HIPAA privacy, security, and breach notification rules. Previously, Adam was a regulator at the U.S. Department of Health and Human Services, where he was responsible for determining how HIPAA rules apply to new and emerging health information technologies and was instrumental in the development of the current HIPAA enforcement process.