Tick Tock: When Is a Data Breach Notice Needed?

clock-2799867_640Notice of a new data breach is posted at least once a day. A frequent feature of many notices is the disclosure that the conduct giving rise to the breach happened months earlier, with the delay sometimes going into years in some instances. The notices typically do not provide much insight into the reasoning for the delays, which gives rise to the question; when should notice of a data breach be provided?

The answer is seemingly straightforward. The HIPAA data breach notification rule states that, absent certain narrow exceptions, a covered entity needs to provide notice without unreasonable delay, which should be no more than 60 days following discovery of the breach. The language “without unreasonable delay” is key. While the rule gives up to 60 days, that full 60 day period should not be used to avoid providing the notice. Instead, notice is supposed to go out as soon as possible. The breach notification rule goes on to set out the required contents of a breach notification, with detail being included as possible. The qualifying language suggests that notice could go out before all relevant details are finalized.

While notification should be provided without unreasonable delay, the timing runs from when the breach is “discovered.” As with any good regulation, the word discovered is specifically defined. For purposes of breach notification, a breach is treated as discovered on the first day that the breach is known or would have been known if reasonable diligence was exercised. The breach is also discovered if any person, other than the person causing the breach, in an organization knows or using reasonable diligence would have known of the breach. The full scope of the definition of discovered underscores that it is very easy for a breach to be known and for the clock to start running to notification.

When implementing the definition of discovered, comments in the regulations emphasized that a broad range of people should be able to discover a breach and bind an entity to that discovery. The commentary offered slight clarity that reasonable care means the exercise of the business care and prudence expected of a person seeking to satisfy a legal requirement. Arguably that statement raises more questions since the level of attention and care can vary greatly depending upon the legal requirement under consideration. At times, it can feel as though certain legal requirements do not receive the full scope of attention and energy deserved, which claim has been applied to HIPAA related compliance efforts.

The plain language of the breach notification rule and the commentary demonstrate the discovery is not intended to be a matter open to discretion or broad interpretation. The goal is to shorten the timeframe in which a breach should be detected, investigated, and then revealed. The goal is not to hide the ball, but to get information out to impacted individuals.

While notification is the broad goal, the rule does include one limited exception for when notification must be delayed. The one exception arises when a law enforcement official requests delay in notification. The request should only be made when the law enforcement official states that notification would impede or investigation or cause damage to national security. Both elements are interesting in that either could be a vague standard and could potentially be invoked for a variety of reasons.

The first exception for not impeding an investigation is the one that could most likely be invoked. For example, many breaches arise from phishing, ransomware, malware, or some other form of external attack on a system. If law enforcement want to pursue a breach in an attempt to track down the attacker, then it would reason that delay in notification would be requested. Since most breach notifications result in some level of attention during a news cycle, any disclosure would draw attention and then reveal that the infiltration is known. Conversely, if a victimized healthcare entity notifies law enforcement and is instructed to keep the attack quiet, then it could be possible to track down the responsible party.

While the description and reasoning for a delay is plausible, the whole concept relies upon the impacted organization actually notifying law enforcement. It may not be possible to know exactly how many organizations tell law enforcement when a breach occurs, but a cursory review of notices does not reveal many instances when a delay is stated, much less than law enforcement has been contacted or involved.

While it is tempting to suggest that law enforcement requests are the reason so many notices do not come out quickly, the truth likely lies elsewhere. Another aspect of the common notice could provide a clue. So many times the notice states that a breach or intrusion happened months before and either was not found until recently or the organization needed to take months in order to determine who and how many individuals were impacted. The first statement raises the question of whether the attack was so hard to find that it could not be discovered or if the organization was just not being diligent enough in reviewing activity. Either scenario is not comforting and arguably at odds with the definition of discovered.

The second statement is more troubling. As noted, the breach notification rule does require a fairly detailed notice to be issued, but at the same time only requires information to be included to the extent known. If not all of the details are known in the first 60 day or less period, then should an organization send an initial notice with more detail to follow? While not preferable from the perspective of allaying worries, that approach could avoid allegations of delay and wanting to prevent notification.

Ultimately, the key is to get notice of a data breach out in a timely manner that aligns with the requirements of the breach notification rule. That means it should be within 60 days of discovering the breach without playing around with what it means to discover the breach. Such an interpretation would likely result in notices coming more quickly and requiring follow up as more detail and impact are determined, but then again conducting an investigation is not really necessary to actually discover the breach. While breaches are inevitable, the real attention should be on enhancing efforts to strengthen defenses and make it harder for the breach to occur in the first place.

Advertisements
Posted in Business, Compliance, Health IT, HIPAA, HITECH, Regulations | Tagged , , , , , | Leave a comment

An Altogether True Reflection

burnout-2161445_640A new twitter account called @EPICEMRparody is garnering a lot of attention for its comments about the burdens placed upon physicians and other clinicians connected to the use of electronic medical records. The account not only skewers the frustrating tedious work and additions to work created by EMRs but other points of frustration to daily practice among physicians.

As can often be said about satire, it is an easy way of getting to inconvenient and harsh truths. Cloaking an issue in humor will draw attention and quick understanding. However, when satire is all to close to the real world, then the frustration can become all too apparent.

The reality being captured by the account was also highlighted in a recent article by Janae Sharp that dove into the issues raised by EMR use. The article highlighted the diverging views from EMR vendors and the physicians using the products. The EMR vendors claim that EMRs are not necessarily a primary driver of physician burnout. The popular storyline is that EMRs drive up the occurrence of burnout because the EMR interferes with the smooth flow between physicians and patients as well as adding numerous administrative burdens onto physicians.

Despite the prevalence of those anecdotes, the EMR vendor industry is pushing back on that narrative. Recently, citing data not yet released, the EMR vendors suggested that despite EMRs being cited as the second leading cause for burnout, there is not a correspondingly high dissatisfaction with EMRs. Without the benefit of the data behind those conclusions, it is difficult to assess the accuracy or even the source of the data.

Regardless of what research has been done or verified, there are some serious issues when it comes to what physicians encounter and must address in daily practice. Some common complaints include being made to feel like basic data entry clerks, not being able to focus on maintaining an actual conversation with patients, not being able to find data, and numerous other issues. All of the complaints come down to the issue of not being able to really engage with patients and pursue what they thought would be their role when entering the practice of medicine.

The concerns are garnering a growing amount of general attention. That means concerns about burnout are being brought to the fore and not just pushed into the background. An open and honest discussion about burnout is essential. Otherwise, physicians could leave medicine altogether or taking other more drastic actions.

What can be done to address burnout? That remains an open question. While there will not be one simple or single solution, just discussing the issue and thinking about how to realign medicine is a significant start. Additionally, recognizing that the initial iteration of health technology tools including EMRs did not result in the expected medical nirvana is also important. From that perspective, many solutions and programs are now more actively considering how to actually make a physician’s practice easier and trying to think about a physician’s actual workflow. Instead of imposing a solution onto a non-existent problem or thinking that the developer knows best, there can be some back and forth or research into where real pain points exist.

 

Progress to reducing burnout will take time, though hopefully not too much when taking into account the toll on physicians and correspondingly patients. Too much is at stake in the healthcare system to let burnout continuing mounting. In the meantime, each person asking themselves how they can help and reaching out to a physician expressing concerns will help. Collective effort will be appreciated.

Posted in Business, EHR, EMR, Health IT, Physicians | Tagged , , , , , , | Leave a comment

Business Associate Agreement Hot Points

laptop-3196481_640If an organization is involved in healthcare, whether as a provider, facility, consultant, vendor or in almost any other capacity, it is highly likely that HIPAA applies to internal operations and relationships with other parties. As should be well known, when a relationship is established with one party providing services for or on behalf of a covered entity (this means a healthcare provider, health plan, or healthcare clearinghouse), then the party providing the service is a business associate. Once a party is a business associate, then a business associate agreement (“BAA”) is needed. In fact, the BAA is not just needed, but mandatory and must be in place before any protected health information is shared.

As a quick refresher, a business associate, as noted above, is any party that provides services for or on behalf of a covered entity and then handles, creates, stores, or otherwise interacts with protected health information for or on behalf of the covered entity. Any entity can become a business associate, even including an entity that is otherwise a covered entity. Additionally, determining a party’s status as a business associate is not an arbitrary one that either party can assert, or created by putting a BAA into place. Instead, it is a matter of assessing whether the definition of a business associate as set out in the HIPAA regulations is met.

Moving beyond the determination of whether a party is a business associate, the real “fun” starts when a BAA is presented. The first question that can arise is who can present the BAA. Really, either party can present the BAA. Oftentimes that decision can be driven by the relative sophistication and awareness of the parties as to regulatory compliance. Surprisingly, that could mean the business associate is the one more cognizant of the need for the BAA.

Lack of awareness by the covered entity is risky. The HIPAA regulations are clear in imposing the obligations to put a BAA into place on covered entities. The focus on covered entities makes sense to some degree since ultimately the covered entity is the party driving the need for the protected health information and establishing the direct relationship with patients, in most instances.

With the presentation of a BAA, the next question goes to what terms should be included. The bulk of a BAA is driven by requirements set out in HIPAA. Both the Security Rule and the Privacy Rule identify specific provisions that must be included for a BAA to be compliant. In fact, the regulatory requirements are technically the full scope of terms that need to be included in a BAA. Another fun fact is that the BAA does not actually need to be a standalone agreement. The regulations would be satisfied if all of the applicable terms are included in any agreement.

While HIPAA requires certain terms to be present, there is still room for some negotiation in how those terms are presented. For the most part, negotiations focus on the timeframes in which business associates will need to perform certain actions or provide certain notices. For example, a BAA will need to reference an individual’s right to access, request an amendment, or ask for a restriction. The business associate is not directly responsible for responding and the covered entity will need the request or other notice sent to it. The covered entity often desires to receive such notices within days of receipt by the covered entity, not the up to 30 or 60 days that could be allowed under the regulations.

Another area where timing becomes of strong interest is around breach notification. Covered entities bear the obligation to notify impacted individuals, the Office for Civil Rights, and the media (in certain instances). Business associates are obligated to notify the applicable covered entity, with the same scope of information that will be needed to provide the broader notification. In each instance, there could be up to 60 days to provide the notification from the time of “discovery,” which is specially defined for HIPAA breach purposes. However, does a covered entity whose patients are impacted by a breach want to wait for up the full 60 day period? The answer is probably not really. That is why so many BAAs will seek to have the business associate provide notice of a breach anywhere from 1-5 days after the initial discovery (though like all of the items highlighted here, there are always exceptions). What is reasonable will be up to the parties.

The real sticking points and obligations though arise from the “extracurricular” type provisions that are not required by HIPAA. The main examples are these provisions are:

  • Indemnification;
  • Reimbursement;
  • Audits; and
  • Insurance.

Each of the above examples seeks to shift liability or responsibility from the covered entity to the business associate or provide examination into the operations of the business associate.

Indemnification and reimbursement can feel like two sides of the same coin. Put simply, indemnification tries to make one party whole by requiring the other party to be responsible for all damages, liabilities, and claims that could arise within the scope of the indemnification. When it comes to BAAs, indemnification is often stated to cover a breach of the BAA and/or a breach of protected health information. Breaches of protected health information represent the area where damages could potentially be quite high, especially depending upon the scope of what is included. If all damages, liabilities, and claims whether direct or indirect are included, then arguably the business associate’s obligation could extend to any matter connected to the breach.

Similarly, reimbursement seeks to obligate the business associate to cover proven expenses incurred by the covered entity. Most often reimbursement is tied to responding to a breach, such as mailing, credit monitoring, or other quantifiable expenditures incurred in the response. Reimbursement is likely more limited than broader indemnification, but could still result in significant monetary impacts.

An audit provision may seek to let the covered entity review a business associate’s operations, whether remotely or on site. Regardless of the type, an audit can be potentially intrusive into a business associate’s operations and could result in access to information from other clients of the business associate. The risks are not one-sided though. If a covered entity succeeds in reserving the right to conduct an audit, will that right be used? What if an issue arises that results in a breach that could have been found by an audit, but no audit occurred? Arguably the Office for Civil Rights could fault the covered entity for not being proactive enough in its own defense. As such, an audit provision should be carefully considered.

Lastly, for now, of the extra provisions is insurance. An insurance provision will try to state the types of coverage to be held by the business associate and with what coverage amounts. Requests for insurance will most often focus on general liability, cyber liability, and umbrella. The types are not usually up for debate, The bigger questions arise over the coverage limits. Covered entities may want very high coverage since a breach will necessarily result in significant costs whereas the business associate will be weighing the cost of obtaining against its revenues and number of clients. Another issue to keep in mind is that a covered entity will not receive the scope of protection it thinks unless it is the only client of a particular business associate. Instead, all of a business associate’s clients will be grabbing for proceeds from insurance in the event of a coverable event, which will necessarily leave everyone less than whole.

As can be seen, BAAs are not without questions and considerations. It is helpful to be aware of these issues and to carefully review every BAA before signing. No agreement should be signed without understanding its implications. Now, proceed with eyes wide open.

Posted in Compliance, Health IT, HIPAA, HITECH, Regulations | Tagged , , , , , | 1 Comment