Web-Tones

Ramifications of Lack of Investment in HIPAA Initiatives!

What happened to Yahoo and its CEO is what can happen to any organization, both large and small, when they fail to invest in their HIPAA initiative. Historically, the healthcare industry has been a notorious laggard in implementing privacy and security. Even now, almost a decade after the HITECH Act was passed, the majority of covered entities and business associates are underinvesting in what amounts to information technology privacy and security 101.

The HIPAA Breach, Privacy and Security Rules ("Rules") do not represent the endgame with respect to fending off the bad guys. The Rules merely represent foundational controls that, from a security perspective, every organization large and small should have in place. Instead, the healthcare industry persists in treating HIPAA as some sort of necessary evil that Big Brother has forced down their throats. It's easy to see why budgets are so small. It will always remain easy to justify placing privacy and security at the bottom of the list for the same reason that Marissa Mayer of Yahoo did. Privacy and security are not sexy. You may have the best security in the world in place BUT it likely won't move your stock price up one iota.

That said, the flip side of the coin is NOT have having foundational security in place (and hopefully more than just that) may cause your reputation to be damaged and your stock price to plummet in a New York minute. Marissa Mayer knew better. She simply chose to roll the dice hoping that it would never happen to Yahoo. That's the same place most healthcare executives are now in. They are much better informed than they were say five years ago. They are simply hoping that it won't happen to them. That's a risky bet given how vulnerable the healthcare industry is to unsophisticated attacks let alone something like ransomware. 

The bad guys know that healthcare is soft and they are coming for you. You can take that to the bank!

Breach Notification Rule Audit Requirements Phase II Protocol

INTRODUCTION

In this post we discussed what the Breach Notification Rule's Audit Protocol requirement was with the Phase I protocol. The Phase II protocol ostensibly adds one more requirement which we highlight below, BUT the significant difference is that the language that HHS uses with respect to what they are demanding for each requirement is more detailed and onerous. This language, we believe, was intended to send a message to the marketplace that the game has changed. Below we review, requirement by requirement, the new language. Unfortunately in some cases, HHS also changed what it named an individual protocol; however the statutory reference remained the same. We use the statutory reference as a guide to illustrates the changes. Everything new will be in blue to highlight the differences. The name of the new protocol will be in "blue bold" and underlined. As you will see, in several cases there are multiple protocols per statutory reference.

CHANGES TO THE PROTOCOL

§164.402 Risk Assessment of Breach.

Inquire of management as to whether a risk assessment process exists to determine significant harm in a breach.      

Definitions: Breach – Risk Assessment

Does the covered entity have policies and procedures for determining whether an impermissible use or disclosure requires notifications under the Breach Notification Rule?

Does the covered entity have a process for conducting a breach risk assessment when an impermissible use or disclosure of PHI is discovered, to determine whether there is a low probability that PHI has been compromised?
If not, does the covered entity have a policy and procedure that requires notification without conducting a risk assessment for all or specific types of incidents that result in impermissible uses or disclosures of PHI?

Obtain and review policies and procedures regarding the process for determining whether notifications must be provided when there is an impermissible acquisition, access, use, or disclosure of PHI.

If the entity does not have a policy and procedure that treats all potential breaches as requiring notifications without conducting a risk assessment, review the covered entity’s risk assessment policies and procedures. Evaluate whether they require the covered entity to consider at least the following four factors:
(i) The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification
(ii) The unauthorized person who used the PHI or to whom the disclosure was made
(iii) Whether the PHI was actually acquired or viewed
(iv) The extent to which the risk to the PHI has been mitigated.

Obtain a list of risk assessments, if any, conducted within the specified period where the covered entity determined there was a low probability of compromise to the PHI. Use sampling methodologies to select documentation of risk assessments to assess whether the risk assessments were completed in accordance with §164.402(2).

Obtain a list of risk assessments, if any, conducted within the specified period where the covered entity determined that the PHI was compromised and notification were required under 164.404-164.408. Use sampling methodologies to select documentation of risk assessments to assess whether the risk assessments were completed in accordance with §164.402(2).

Definitions: Breach - exceptions Unsecured PHI

Did the covered entity or business associate determine that an acquisition, access, use or disclosure of protected health information in violation of the Privacy Rule not require notifications under §§164.404-164.410 within the specified period?

• If yes, did the covered entity or business associate determine that one of the regulatory exceptions to the definition of breach at §164.402(1) apply? If yes, obtain documentation of such determination. Use sampling methodologies to select and review documentation that such were completed in accordance with §164.402.

• If yes, did the covered entity or business associate determine that the breach did not require notification, under §§164.404-410, because the PHI was not unsecured PHI, i.e., it was rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified in the applicable guidance? If yes, obtain and review documentation. Use sampling methodologies to select and review documentation that such were completed in accordance with §164.402.

NOTE: It appears that §164.402 was split into two requirements thereby changing the total count to 11 instead of 10. Substantively there are no changes.

§164.404 Notification to Individuals.

Inquire of management as to whether a process exists for notifying individuals within the required time period. Obtain and review key documents that outline the process for notifying individuals of breaches.

§164.404(a) Notice to Individuals

Does the covered entity have policies and procedures for notifying individuals of a breach of their protected health information.

Obtain and review a list of breaches, if any, in the specified period involving 500 or more individuals. Obtain and review documentation of notifications provided to the affected individuals. Determine whether notifications were provided to individuals consistent with the requirements in §164.404(a)(1).

§164.404 Timeliness of Notification.

Inquire of management as to whether a process exists for notifying individuals within the required time period. Obtain and review key documents that outline the process for notifying individuals of breaches. Verify, if any breaches have occurred, that individuals were notified within 60 days.

§164.404(b) Timeliness of Notification

Were individuals notified of breaches within the required time period? Inquire of management.

Obtain and review the policies and procedures for notifying individuals of breaches and determine whether such policies and procedures are consistent with §164.404, including providing notification without unreasonable delay and in no case later than within 60 days of discovery of a breach.

Obtain and review a list of breaches, if any, in the specified period and documentation indicating the date individuals were notified, the date the covered entity discovered the breach, and the reason, if any, for delay in notification to determine whether all individuals were notified consistent with §164.404(a), (b).

§164.404 Methods of Individual Notification.

Inquire of management as to whether a process exists for notifying an individual or an individual's next of kin of a breach. Obtain and review formal or informal documentation that provide the process and method for notifying individuals of a breach and compare it to established performance criteria. Inquire of management of the process for identifying an individual's contact information or next of kin and the process for follow-up when there is insufficient contact information. Obtain and review formal documentation that identifies the methods for providing notification where contact information is insufficient or out-of-date and compare to established performance criteria.

§164.404(d)Methods of Notification

Does the covered entity have policies and procedures for notifying an individual, an individual's next of kin, or a personal representative of a breach? Inquire of management.

Obtain and review the covered entity’s policies and procedures for notifying individuals, next of kin, or personal representatives of a breach to determine whether they are consistent with §164.404(d), including the following:

• Do the policies and procedures provide that notice will be provided by first-class mail unless the individual has agreed to receive an electronic notice?
If there is a process for individuals to agree to receive electronic notice, is there also a process to address circumstances where an individual withdraws such agreement?

• Do the policies and procedures provide that the covered entity will send the notification to the next of kin or personal representative where the covered entity has knowledge that the individual is deceased and has the address of the next of kin or personal representative?

• Do the policies and procedures address the provision of substitute notice consistent with §164.404(d)(2), including:
o Alternative means for providing notification to individuals if there is insufficient or out-of-date contact information for fewer than 10 individuals
o If insufficient or out-of-date contact information for 10 or more individuals
- Posting a conspicuous notice on the home page of the covered entity’s web site or publishing conspicuous notices in major print or broadcast media in the geographic area(s) where the affected individuals likely reside
-Establishing a toll-free phone number that remains active for at least 90 days.

Did the covered entity determine that there were any breaches within the specified period that required substitute notice? Obtain and review documentation of substitute notices:
1. If insufficient or out-of-date contact information for fewer than 10 individuals, documentation of notice provided by alternative means, such as a log of telephone call
2. if insufficient or out-of-date contact information for 10 or more individuals, documentation of a conspicuous posting on the home page of the covered entity’s web site or a copy of conspicuous notices in major print or broadcast media and documentation of a toll-free phone number that remained active for at least 90 days.
Use sampling methodologies to select notifications to be reviewed and verify that the notices include the elements required by §164.404.

§164.404 Content of Notification.

Inquire of management to determine if there is a standard template or form letter for breach notification. Verify that, if any breaches have occurred, the notification to the individuals included the required elements of this section.

§164.404(c)(1) Content of Notification

§164.404(c)(1)
Content of Notification
Does the covered entity have policies and procedures for providing individuals with notifications that meet the content requirements of §164.404(c)? Inquire of management; obtain and review policies and procedures. Evaluate if the specifications at §164.404(c) are met.

Inquire of management whether the covered entity has used a standard template or form letter for notification to individuals for all breaches or for specific types of breaches. If the covered entity has used a standard template or form letter for breach notification, obtain and review the document. Evaluate whether it includes this section's required elements.

Obtain and review a list of breaches, if any, in the specified period and documentation of written notices sent to affected individuals for each breach. Use sampling methodologies to select notifications sent to individuals to be reviewed and verify that the notices include the elements required by §164.404(c).

§164.406 Notification to the media.

Inquire of management as to whether a process exists for notifying media outlets for breaches of more than 500 individuals' PHI and compare it to established performance criteria. Verify if any breaches of unsecured PHI have involved more than 500 individuals and have required notification of media outlets.

§164.406 Notification to the Media

Does the covered entity have policies and procedures for notifying media outlets of breaches affecting more than 500 residents of a State or jurisdiction? Obtain and review policies and procedures. Evaluate whether the specifications at §164.406 are met.

Obtain and review a list of breaches, if any, in the specified period affecting more than 500 residents of a State or jurisdiction. Obtain and review documentation to verify that the media notifications included the elements required by §164.406.

§164.408 Notification to the Secretary.

Inquire of management as to whether there have been any breaches of unsecured PHI and verify that the Secretary was notified. Verify if any breaches of unsecured PHI have involved more than 500 individuals and have required contemporaneous notification to the Secretary. Verify if any breaches of unsecured PHI have involved less than 500 individuals and have required annual notification through the HHS website.

§164.408 Notification to the Secretary

Does the covered entity have policies and procedures for notifying the Secretary of breaches involving 500 or more individuals? Does the covered entity have policies and procedures for notifying the Secretary of breaches involving less than 500 individuals? Obtain and review policies and procedures. Evaluate whether the specifications at §164.408 are met.

Obtain and review a list of breaches, if any, in the specified period involving 500 or more individuals. Obtain and review documentation of notifications provided to the Secretary. Determine whether contemporaneous notifications were provided to the Secretary consistent with the requirement in §164.408. Use sampling methodologies to select notifications to be reviewed and verify that the notices include the elements required by §164.408.

Obtain and review a list of breaches, if any, in the specified period involving fewer than 500 individuals. Obtain and review documentation of notifications provided to the Secretary . Evaluate whether the notifications were provided to the Secretary within 60 calendar days of the end of the calendar year in which the breach was discovered, consistent with the requirement in §164.408. Use sampling methodologies to select notifications to be reviewed and verify that the notices include the elements required by §164.408.

§164.410 Notification by a business associate.

Inquire of management as to whether there have been any breaches of unsecured PHI for a business associate and verify that the covered entity was notified. Obtain the standard business associate agreement to verify that the breach and notification elements are included in the agreement.

§164.410 Notification by a Business Associate

Did the business associate or subcontractor determine that there were any breaches of unsecured PHI within the specified period?

If yes, obtain copies of the notification(s) sent by the business associate (or subcontractor) to the covered entity (or business associate for breaches by subcontractors). Evaluate whether the business associate or subcontractor sent the notifications consistent with the requirements at §164.410. Use sampling methodologies to select notifications to be reviewed and verify that the notices include the elements required by §164.410.

§164.412 Law enforcement delay.

Inquire of management as to how notifications are delayed in case of law enforcement requests. Obtain and review documentation of the process to delay notifications in case of law enforcement requests.

§164.412 Law Enforcement Delay

Does the covered entity or business associate have policies and procedures regarding how the covered entity or business associate would respond to a law enforcement statement that a notice or posting would impede a criminal investigation or damage national security?

Has the covered entity or business associate delayed notification of a breach of unsecured PHI pursuant to such a law enforcement statement?

If yes, obtain and review documentation of any such law enforcement statement. Evaluate whether the covered entity or business associate acted in accordance with §164.412. Use sampling methodologies to select notifications to be reviewed and verify that the notices include the elements required by §164.412.

§164.414 Burden of Proof.

Inquire of management as to whether a risk assessment process exists to determine significant harm in a breach. Inquire of management as to whether a process exists to ensure that all notifications were made as required or that the impermissible use or disclosure did not constitute a breach. Obtain and review documentation of uses or disclosures that were not determined to be breaches and the corresponding risk assessment documentation.

§164.414 Burden of Proof.

NOTE: HHS does NOT make any requests for documents for this requirement. The "protocol" simply states covered entities and business associates have the burden proof with respect to whether Breach Notification was triggered.

SUMMARY

What are we to make of all of this? First of all there is no reason to panic. There have been NO SUBSTANTIVE CHANGES to the regulations since the Omnibus Rule (circa 2013). Which means that NONE of the underlying requirements of the Breach Notification Rule has changed. Remember, HHS can only audit you on the requirements contained in the regulations. They can't "make up" new requirements for an audit. For our Subscribers nothing changes because our Breach Notification Framework distilled the underlying requirements from the "get go." If you're relying on other products then you need to ask the right questions. There is no need to guess what HHS might ask you in an audit. If you are in compliance with the underlying requirements then you have visible, demonstrable evidence to satisfy ANY audit question that might come your way. In subsequent posts we will dissect what we believe HHS' intentions are for each requirement.

 

 

What is Willful Neglect?

Risk Mitigation Q&A?

I believe many of you will find this conversation of interest. It's from our Director's Cut series.

What's the essence of the HIPAA Security Rule?

The Security Rule is a set of regulations which requires that your organization identify Risks, mitigate Risks, and monitor Risks over time in order to ensure the Confidentiality, Integrity, and Availability of your organization's ePHI. That's it more or less. This post is intended to provide you the basic concepts that help you understand, engage, and ultimately master the details. For the uninitiated the Security Rule is nothing less than a regulatory monster. The only way to conquer it is to "hug the monster." However, this post just provides a brief introduction to the monster so that over time you might be comfortable enough to "hug it."

In order to understand the Security Rule you must become familiar with some of its technical jargon. Much of this jargon can be found in NIST Special Publication 800-30(Guide for conducting Risk Assessments), a document that should prove quite useful to those engaged in implementing the Security Rule. The Security Rule ("Rule") is replete with technical terms. In addition, any description of how to comply with the Rule will also necessitate the use of additional technical terms. The NIST document breaks down the technical jargon in a manner that is readily understood by the lay person. It is not written for the technical expert; although we believe even the latter may derive significant value from it. The Rule contains its own Definitions in 164.304. 

The intent of this post is not to over simplify or trivialize what is in fact a very complex set of regulations, but rather to ensure that the "end game" remains clearly visible as you grapple with the Rule's complexity. It is important to understand compliance with the Rule is a project with a beginning, a middle, but no discernible end. It is the quintessential wicked problem.  New Threats, Vulnerabilities, and Risks will continue to emerge over time as your operational environment changes. It is critical to identify common Threats, Vulnerabilities and Risks (“TVRs”) that likely already exist in your operational environment. Once your organization becomes familiar with the identification process, you will quickly be able to identify other TVRs. That's why Expresso comes pre-populated with 150 Risks and their corresponding controls.

The Threat, Vulnerability, and Risk Matrix

Risk identification requires your organization to gather Threats, Vulnerabilities, and Risks and associate them with your Operations, Assets, and Individuals (i.e. Security Objects as they are referred to in Expresso). Although a daunting exercise on its face, the reality is that many Threats and Vulnerabilities have already been identified for healthcare operational environments and, therefore, you need not start with a "blank sheet of paper." The majority of your time should be spent mitigating those Risks that pertain specifically to your organization in order to reduce the level of Risk to what is "reasonable and appropriate." 

Risk Mitigation is nothing more than the systematic reduction or elimination of Threats and/or the “plugging” of Vulnerabilities vis-à-vis the implementation of your Risk Management strategy in order for your Risk Response(s) to be commensurate with the “reasonable and appropriate” safeguards required to protect your ePHI within your organization. No organization is capable of eliminating all Risk and, in any case, that is not required by the Rule. What is required is to reduce Risks to levels that are “reasonable and appropriate.”

Risk Monitoring is the ongoing self-awareness of your organization’s Risk environment, Risk Management program, and associated activities to support Risk decisions. It is the principal reason that the Rule's implementation has no discernible end. For example, Risk Assessments must be performed periodically due to changes in your operational environment. Each new Risk Assessment will almost certainly lead to the identification of new/changed TVRs and the triggering of additional steps in your Risk Management program. Your implementation of the Rule is therefore recursive (i.e. the application of the same set of steps over and over) and never ending.

The First Two Security Rule Specifications

The first two specifications of the Administrative Safeguards (i.e. Risk Analysis and Risk Management) are foundational to your organization’s implementation. Both are repeatable processes that should provide a detailed understanding of Risks to your organization’s ePHI and of the Security Controls your organization needs to effectively manage those Risks over time. Executing these processes with a degree of rigor will ensure the Confidentiality, Availability and Integrity of your ePHI. Proper execution protects your organization against any reasonably anticipated threats or hazards to the security or Integrity of your ePHI, and also protects it against any reasonably anticipated uses or disclosures of ePHI that are not permitted or required under the HIPAA Privacy Rule.

Conclusion

To summarize, the essence of the Rule is to: Identify Risks related to your ePHI, Mitigate Risks related to your ePHI, and Monitor Risks related to your ePHI. These steps must be repeated over time as changes to your operational environment occur (e.g. new applications, services, hardware, etc.) or a material change in the law occurs.

 

 

Breach Notification Rule Audit Requirements

The HHS Audit Protocol for the Breach Notification Rule is kind of a odd bird. First of all, it is very short compared to its importance in the grand scheme of things in the HIPAA universe (only 10 requirements). Second, it is more about "things" that you should be prepared to do rather than "things" you are (or should be) currently doing. If you look at HHS' Audit Protocol for sections 164.404 through 164.414 you will notice that the "protocol" doesn't do much more than repeat what is contained in the regulations AND, in addition, it provides for certain "inquiries." Now to be sure the entire HHS Audit Protocol follows this format but in the case of the Breach Notification Rule the inquiries are about an "eventuality" that may never occur.

The following table contains all the HHS Audit Protocol requirements related to Breach Notification. There are only ten (10) compared to eighty-one (81) for the Privacy Rule and seventy-eight (78) for the Security Rule. The overall numbers have changed slightly since OCR's second audit protocol release BUT none of the requirements have changed that underpin them.

Section	Description	Inquiry
§164.402	Risk Assessment of Breach	Inquire of management as to whether a risk assessment process exists to determine significant harm in a breach.
§164.404	Notification to Individuals	Inquire of management as to whether a process exists for notifying individuals within the required time period.   Obtain and review key documents that outline the process for notifying individuals of breaches.
§164.404	Timeliness of Notification	Inquire of management as to whether a process exists for notifying individuals within the required time period.   Obtain and review key documents that outline the process for notifying individuals of breaches.   Verify, if any breaches have occurred, that individuals were notified within 60 days.
§164.404	Methods of Individual Notification	Inquire of management as to whether a process exists for notifying an individual or an individual's next of kin of a breach.   Obtain and review formal or informal documentation that provide the process and method for notifying individuals of a breach and compare it to established performance criteria.   Inquire of management of the process for identifying an individual's contact information or next of kin and the process for follow-up when there is insufficient contact information.   Obtain and review formal documentation that identifies the methods for providing notification where contact information is insufficient or out-of-date and compare to established performance criteria.
§164.404	Content of Notification	Inquire of management to determine if there is a standard template or form letter for breach notification.    Verify that, if any breaches have occurred, the notification to the individuals included the required elements of this section.
§164.406	Notification to the media	Inquire of management as to whether a process exists for notifying media outlets for breaches of more than 500 individuals' PHI and compare it to established performance criteria. Verify if any breaches of unsecured PHI have involved more than 500 individuals and have required notification of media outlets.
§164.408	Notification to the Secretary	Inquire of management as to whether there have been any breaches of unsecured PHI and verify that the Secretary was notified.   Verify if any breaches of unsecured PHI have involved more than 500 individuals and have required contemporaneous notification to the Secretary.   Verify if any breaches of unsecured PHI have involved less than 500 individuals and have required annual notification through the HHS website.
§164.410	Notification by a business associate	Inquire of management as to whether there have been any breaches of unsecured PHI for a business associate and verify that the covered entity was notified.   Obtain the standard business associate agreement to verify that the breach and notification elements are included in the agreement.
§164.412	Law enforcement delay	Inquire of management as to how notifications are delayed in case of law enforcement requests.   Obtain and review documentation of the process to delay notifications in case of law enforcement requests.
§164.414	Burden of Proof	Inquire of management as to whether a risk assessment process exists to determine significant harm in a breach.   Inquire of management as to whether a process exists to ensure that all notifications were made as required or that the impermissible use or disclosure did not constitute a breach.    Obtain and review documentation of uses or disclosures that were not determined to be breaches and the corresponding risk assessment documentation.

 

Essentially almost every requirement wants to know if management has a process in place to deal with the requirement and whether there exists documentation (e.g. templates) that underpin the process. However, there are exceptions to this general rule. If you look at §164.402 under the rule you notice that it is labelled "Definitions." It has nothing directly to do with whether or not you have a Risk Assessment process in place but the protocol for this section asks about a Risk Assessment process. Of course a Risk Assessment is an implementation specification of the first standard of the Security Rule, what's it doing here? One answer is that it is HHS' Audit Protocol and they can do with it what the will. But more than likely it is HHS' way of emphasizing just how important a Risk Assessment is. How are your going to know there's a breach if you have never performed a Risk Assessment? 

Sure, you would probably know there was a breach even if you had never performed a Risk Assessment, but likely you would not have the necessary foundational information (e.g. an inventory of information systems) to effectively report on a breach. Notice that this audit protocol inquires into whether or not various processes exists, but you could summarize it by asking the following question of your organization: "Do you have a methodology in place, including the tools and templates that underpin it, with respect to breach notification?" In other words, are you prepared should a breach occur. If you can answer yes to this question then you should do well on this part of the audit.

For our subscribers our Breach Notification Framework and related training is all that you need to prepare for a Breach Notification Rule Audit. We provide, among other things, the following: (1) an analytical framework for determining whether breach notification is triggered; (2) a security incident document to track information related to the breach; (3) model letters to individuals, the secretary and media and much more. Of course, you could "roll your own" or purchase a competing solution in the HIPAA marketplace, but you are going to need something like our offering to effectively make a good faith argument that you are complying with the Breach Notification Rule as required by HHS' protocol.

Of course, if HHS is performing a comprehensive audit it will attempt to provide coverage of all 169 requirements in some way, shape, or form. However, if there has been a breach perhaps HHS will focus on these ten requirements and then branch out from there. There are lots of different place HHS could go starting with these ten requirements. We often say in our webinars that if we were conducting an audit the first question we would ask (right after "Who is your named Privacy Officer" and "Who is your named Security Officer?") is "Tell us about how you track Security Incidents?" If you are not tracking Security Incidents then the probability is high that you are going to fail the Breach Notification Rule part of the audit.

HIPAA Lawsuits: A De Facto Right of Action?

This post discusses HIPAA related lawsuits and why we may see an explosion of one particular category of HIPAA lawsuits in the next few years. In general, there are four categories of suits that can be thought of as "HIPAA related:" (1) an action by HHS to enforce sanctions for violations (i.e. in the rare case where a covered entity ("CE") or business associate ("BA") does not settle); (2) an action brought by a state attorney general on behalf of the citizens of a state (i.e. as provided for in HITECH Act Section 13410); (3) a private "class action" suit brought under some a state law theory (usually state breach notification law or negligence); and (4) an action brought by a single individual under state law theory of negligence.

The categories above are not exhaustive. They merely represent a useful way to think about various HIPAA lawsuits that we read about. This post focuses on category four and posits why we may see an explosion of these kinds of suits over the next several years. 

In order to set the stage, we first must remind readers that individuals cannot bring an action directly under HIPAA. HIPAA does not allow individuals to bring suit for HIPAA violations, no matter how egregious. Under HIPAA, all that an individual patient may do is the following: (1) file a complaint with HHS (i.e. on its website); and (2) file a complaint with their state attorney general (we are aware of no formal process for doing the latter). 

 BUT, you may be thinking, didn't an individual patient win a significant judgement against Walgreens for over $1M dollars. The answer to that question is yes. However, the distinction is that the patient did not bring suit "under HIPAA," rather, the patient sued under a state law theory of negligence. The HIPAA requirements were simply used as the "standard of care."

A De Facto Right of Action under Negligence Law

Before we discuss the import of individual cases such as Walgreens, we need to cover some Negligence Law 101 concepts, otherwise you are likely to get "lost in the weeds" of the legal jargon. In order to prevail on a theory of negligence the plaintiff (i.e. the individual patient for our purposes) must prove, by a "preponderance of the evidence," the following four elements:

1. Duty: That the CE or BA had a legal duty to protect the patient's PHI. HIPAA clearly establishes such a duty.
2. Breach: That the CE or BA breached the "standard of care" that pertains to the specific Duty alleged. Here, as we shall discuss, a number of courts have held that the HIPAA requirements can be used as the "standard of care." 
3. Causation: That the Breach caused harm to the patient. Note: we are going to ignore the fact that "Causation" is two elements in one: (1) cause in fact; and (2) proximate cause.
4. Damages: That that the Harm caused by the Breach resulted in actual damages to the patient. Note: the term "actual damages" under negligence law is a legal term of art. Actual damages are distinguished from "pain & suffering/emotional" damages. That said, it remains unclear whether "emotional damages" will be granted in a HIPAA case depending on the facts (e.g. the CE releases a patient's PHI indicating that the patient has HIV to the patient's employer).

Unless all four elements are proven, the CE or BA wins. To be sure, the simple fact that HIPAA can be used as the "standard of care" does not get a patient all the way home. For example, many courts have pushed back on the "actual damages" that result from a breach, although in Walgreens the patient obviously prevailed on all the elements.

The Standard of Care

 What does it mean for HIPAA to be the "standard of care" in a negligence action? The "standard of care" is inextricably intertwined with the first two elements. The "standard of care" represents the "measure" of the Duty owed and also is the "standard" by which a Breach is established. In short, if in a negligence action regarding PHI, it is established that the alleged conduct of the CE/BA violated HIPAA, then that will almost certainly establish that Breach (element 2) has been satisfied (i.e. met). Keep in mind that Breach, as used in negligence law, has nothing (directly) to do with how breach is defined under the HITECH Act. So to put it another way, if you violate HIPAA vis-a-vis the conduct that the patient alleges, then two of the four negligence elements have been met. Further, because the HIPAA regulations clearly provide a well defined "standard of care," establishing the first two elements should be relatively straight forward for the plaintiff. 

Holding that HIPAA is the "standard of care" under a negligence action is nothing new. In 2007 (i.e. prior to the HITECH Act) a NC Appeals Court held that HIPAA could be used as the "standard of care" in the kinds of negligence actions we are discussing here. Since then, many courts, including the CT Supreme Court have held analogously. What was "shocking" in the Walgreens case (in addition to the jury's $1.4M judgment) was the fact that the Court allowed the jury to decide whether Walgreens could be held accountable, under a theory of respondeat superior (let the master answer), for the intentional wrong doing of an employee. In other words, the $1.4M judgement was levied directly against Walgreens the party with the "deep pockets" (and presumably against the individual employee as well). Under HIPAA , to the best of our knowledge, the intentional wrong doing of an employee has NOT resulted in the master being held liable, until Walgreens.

An Explosion of HIPAA Negligence Suits?

Knowledgeable watchers of this space have been predicting a significant growth in HIPAA negligence suits since 2007. Heretofore we haven't seen this prediction realized. What's different now? Well, for starters, the HIPAA compliance world has been turned upside down by the HITECH Act since 2007, especially in the form of the 800 pound gorilla of the Breach Notification Rule. Second, the emergence of the ePatiert community means that there are a LOT more patients that not only want access to their PHI, but ALSO know that, under HIPAA, they are entitled to get it. Third, the public in general is much more aware of cybersecurity issues than they were back in 2007. If this awareness were not already at a high level, the sensationalist nature of the cyberattack against Sony for "The Interview" has put that question to rest.

In short, the HIPAA compliance "narrative" has been transformed not only by legislation, but also by the 24/7 365 "always on" online universe that we all now inhabit. News travels fast. A quick search on Google will inform an aggrieved patient of what is possible, and given that we are "by nature" a litigious society, the rest of the story will unfold as scripted. There are likely a significant number of HIPAA Lawyers (to the extent that such a "species" actually exists) that have counselled individuals that their only choice was to file a complaint with HHS. This is true despite the fact that, as discussed here, HIPAA as the "standard of care" is nothing new. Why? Because as a general rule lawyers specialize. A "HIPAA Lawyer" is probably NOT a personal injury lawyer. It's the latter that specializes in negligence law.

Conclusion

It's a "perfect storm" of events that is likely to trigger an explosion of HIPAA negligence suits. The same attorneys that sue doctors for malpractice will probably take the lead here. Further, it's not hard to find patients that are unhappy with their healthcare providers. How many of us still think of our doctors as "God Like" figures? How many of us are happy with the "five minute drill" that masquerades as a doctor's visit? It's hard to imagine that our current "healthcare" system is nothing more than "disease care."

Sure, the docs are not the only ones to blame. The business model (i.e. fee for service) that they have relied on for over 100 years is being completely disrupted (and rightfully so); but they don't call the shots vis-a-vis how the game is played. Someone else, the payers (i.e. the insurance companies and the U.S. government) make the rules and call the shots. The doctors have been forced into the "five minute drill" and are struggling in this brave new world like the rest of us. Still, when it comes to HIPAA, the buck stops with the CEs and BAs. Patients will hold them accountable. Why? Because its the law, and because "this is not your Daddy's HIPAA anymore!"

Launch your HIPAA Initiative in Ten (10) Steps

Notice that the title of this post does not say 10 easy steps. Also notice that the title states "Launch" (not "Complete") your initiative. You will certainly have made significant progress at the end of these 10 Steps but in no way do we mean to imply that you will be done. Clearly you won't be. However, if you are a long time reader you know that we assert, every chance we get, that you will never be done with your HIPAA initiative because by definition, it is a ongoing process. Also, for the sake of transparency, we use our Agile Methodology Project Plans to describe the 10 steps. That said, these 10 steps are written generally so as to apply no matter what purchased or "home grown" tool sets you may be using. 

1. Designate a HIPAA Privacy Officer and Security Officer (Track = "Foundation") 

 

1.1. Present candidates with the necessary credentials or candidates willing to obtain the necessary credentials to the executive team.

1.2. Name a HIPAA Privacy Officer.

1.3. Name a HIPAA Security Officer.

1.4. Distribute designations to your entire WorkForce.

2. Disseminate Model Policies (Track = "Foundation")

2.1. Present the model policies (e.g. Security Rule Policy, Privacy Rule Policy, Breach Notification Policy and others as required for your organization).

2.2. Make changes to the policies based on executive team feedback.
2.3. Allow the executive team to review the FINAL policies.
2.4. Distribute the policies to the entire organization and ensure that each individual indicates that he/she has read and understood the policy by signing his/her name in the signature block.
2.5. Scan signed policies and store them in the Organization's Compliance Repository
2.6. Distribute policies to new Workforce Members as required.
2.7. Once a year review the policies with the executive team to ensure continued applicability. 

3. Training & Awareness (Track = "Foundation")

3.1. Introduce the training program to executive team and get "buyin"

3.2. Introduce the training program to the rest of the staff

3.3. Have Key stakeholders (i.e. Privacy Officer, Security Officer, one Administrative Staff, and one Clinical Staff) ("Core Training Team") review the exam(s) and participate in the training program; including taking the exams.

3.4. Depending on the size of the organization cross functional team(s) of Workforce Members participate in joint training; take the exam, and signoff on having taken and passed the exam.

3.4.1. Schedule which Workforce member will take which classes and ensure availability for the majority of the class (Workforce members unavailable will have to take the class at some other time or on their own).

3.4.2. Each class discusses the training and provides feedback to the Core Training Team.
3.4.3. Any individual that does not make 70% or better on an exam must go through the training again and retake the exam.
3.4.4. The Core Training Team may want to produce several variations of each test to make test re-takes meaningful.

3.5. Executive team members participate in "regular" classes along with other Workforce Members

3.6. Get feedback from the executive on the training program and make modifications as required.

 

4. Compliance Repository (Track = "Foundation") 

4.1. Review with the executive team where the Compliance Repository should be stored and maintained. An in-house Intranet/Wiki (secured obviously on a need to know basis) is a perfect place for it. A "network share" would work just as well. If you are tempted to store on it on the Cloud then it better be on your own private cloud or you will need a Business Associate Agreement with your cloud provider (e.g. Microsoft, Amazon, etc.).

4.2. Your electronic Compliance Repository is the equivalent of your "old 3-ring binder" only much more effective. Here you can clearly determine what the latest version of a policy is (i.e. a single version of the "truth"). However, your Compliance Repository also stores your written processes and also process results (e.g. your training tracking spreadsheet, your security incidents, your patients and Workforce Member's signed policies). In other words your Compliance Repository is where you store your Visible, Demonstrable, Evidence of compliance (i.e. proof that your organization is complying with your policies and processes).
4.3. Create the Root folder/page ("Folder") and call it Compliance Repository (or something to that effect).

4.3.1. Under the Root create a directory for "Policies and Procedures"-we suggest that you further breakdown this folder in to subject matter domains such as: 

4.3.1.1. Privacy Rule

4.3.1.2. Security Rule
4.3.1.3. Breach Notification Rule
4.3.1.4. Cloud
4.3.1.5. Social
4.3.1.6. Mobile
4.3.1.7. Disaster Recovery
4.3.1.8. Risk Assessments
4.3.1.9. Risk Management
4.3.1.10. Patient requests under the Patients' Bill of Rights ("PBR")-§§164.520 through §§164.528
4.3.1.10.1. Notice of Privacy Practices §164.520
4.3.1.10.2. Rights to Request Restrictions §164.522
4.3.1.10.3. Rights to Access PHI §164.524
4.3.1.10.4. Rights to Amend PHI §164.526
4.3.1.10.5. Rights for an Accounting of Disclosures for PHI §164.528
4.3.1.11. Etc.

4.3.2. Under the Root create a Folder for Business Associates-further break down this Folder into one Sub-Folder for each Business Associates.
4.3.3. Under the Root create a Folder for Sub-Contractors-further break down this Folder into one Sub-Folder per Sub-Contractor.
4.3.4. Under the Root create a Folder for Workforce Members-further break down this Folder into one Sub-Folder per Member.
4.3.5. Under the Root create a Folder for Training-further break down this Folder into types of Training.
4.3.6. Under the Root create a Folder for Security Incidents-further breakdown this Folder into one Sub-Folder per incident with a date attached to the Sub-Folder name.
4.3.7. Create additional Folder and Sub-Folders under the Root as required.
4.3.8. Ensure that the Compliance Repository gets backed up on a daily basis and is otherwise protected from a Disaster Recovery perspective like you would protect PHI. 

5. Risk Assessment (Track = "Foundation")

 

5.1. Present the rationale for doing the current Risk Assessment ("RA") to the executive team (e.g. baseline, Meaningful Use, post a security incident, after a year, etc.).

 

5.1.1. Get approval for budget.

5.1.2. Get approval for resources.

5.1.3. Identify third parties vendors needed (e.g. IT security consultants)

5.2. Conduct the RA.

5.2.1. Gather and capture inventory data pertaining to Security Objects

5.2.2. Identify Threats and Vulnerabilities

5.2.3. .Assess current Security Controls.

5.2.4. Determine the likelihood of a Threat.

5.2.5. Determine the potential Impact of a Threat.

5.2.6. Determine the level of Risk associated with Threat/Vulnerability pairs. 
5.2.7. Identify new/modified Security Controls and finalize documentation.

5.3. Present results of RA to executive team and revisit the budget and resources required based on the number of Risks to be "attacked."

 

6. Business Associates (Track = "Foundation")

 

6.1. Ensure the appropriate Business Associate Agreements ("BAAs") are in place with all Business Associates and executed by both parties.

6.2. Review of BAAs on an annual basis at a minimum to ensure continued compliance by both parties.

6.3. Get "Satisfactory Assurances" from your Business Associate that they are comply with the HIPAA Rules in a manner required by the HITECH Act and corresponding regulations, and by the BAA.

 

6.3.1. Request to review Visible, Demonstrable, Evidence of Compliance

6.3.1.1. Policies

6.3.1.2. Processes

6.3.1.3. Tracking Mechanisms (i.e. pursuant to process results)

 

6.3.2. Additional Due Diligence for Business Associates that "store or maintain" your PHI

6.3.2.1. Get "Satisfactory Assurances" as to the Business Associate's encryption strategy

6.3.2.2. Review the implementation of the Security Rule's Administrative, Technical, and Physical Safeguards

6.3.2.2.1. A more detailed review of the Business Associate's last Risk Assessment is required

6.3.2.2.2. A more detailed review of the Business Associate's Risk Management Program is also required.

6.3.2.2.3. Where necessary and practical may onsite visits to ensure that the Business Associate is complying with applicable law (both

state and federal)

6.3.2.2.4. Where onsite visits are not practical, make virtual visits any number of cost effective tools now available in the marketplace that supports this kind of activity.

6.4. Business Associate Incident Reporting

6.4.1. Ensure that Business Associates clearly understand the reporting requirements under the Breach Notification Rule.

6.4.2. Ensure that Business Associates clearly understand what triggers breach notification.

6.4.3. Have a Breach Notification Communication plan thirty days after executive/renewal of the BAA in all cases where the Business Associate.  

"stores and maintains" ePHI on your behalf.

 6.5. International Business Associate Issues

 6.5.1. Get "Satisfactory Assurances" that your International Business Associates are in compliance with privacy & data protection laws of

their country of origin

6.5.2. Ensure that International Business Associates comply with the HIPAA Rules using the BAA as the controlling device.

6.5.3. Ensure that International Business Associates agree to the jurisdiction of U.S. Courts in a forum and venue of your choosing.

 

7. Incident Tracking & Reporting (Track = "Foundation")

 

7.1. Present the rationale for a Security Incident Tracking System ("SITS") to the executive team.

7.2. Get approval for budget and resources to develop and deploy the SITS.

7.3. Distribute the Breach Notification Policy for signature by all Workforce Members. Ensure that everyone has indicated that they have read and understood it.

7.3.1. Provide specifics about who security incidents should be reported to

7.3.2. Provide specific about how security incidents should be reported

7.3.3. Indicate that there will be Sanctions against Workforce Members who fail to report security incidents

7.4. File signed Breach Notification Policies in the Compliance Repository in the Workforce Member's Sub-Folder.

7.5. Follow-up with Breach Notification Training if you have not already accomplished this objective in another Sprint.
7.6. Ensure that everyone takes and passes the Breach Notification Training exam. 
 

8. Patient's Bill of Rights (Track = "Essential")

 

8.1. Notice of Privacy Practices ("NOPP")-review/revise processes for distributing, updating and revising your NOPP as required
8.1.1. Walk In-in person visits.

8.1.2. Electronic-visits to your "Portal" on the Internet

8.1.3. Updates & Reviews-vetting for amendments and revisions

8.2. Access to PHI
8.3. Amendment to PHI
8.4. Accounting for Disclosures

9. Patients' Bill of Rights: Access to PHI (Track="Essential")

 

9.1. Ensure that your Organization understands the changes to the right to access of PHI introduced by the HITECH Act Section 13405(e) (i.e. with respect to the use of an EHR), and the changes introduced by the Omnibus Rule (i.e. with respect to any electronic PHI including, but not limited to, documents in the following format: MS Word, Excel, PDF, etc.).

9.2. Ensure that you adequately train Workforce members that have responsibility for fulfilling PHI access requests:
 

9.2.1. Job titles must reflect this responsibility

 

9.2.2. Designated Workforce members must clearly understand the "due process" requirements of providing access (e.g. 30 day requirement unless an extension is asked for and obtained in writing).

  

9.2.3. The Designated Workforce member processing the request is responsible for delivering the PHI to the patient in the form requested

 

9.2.4. If the access request is denied, the designated Workforce member must provide the patient the reason for denial in writing

 

9.3. Ensure each patient access request is signed, dated, and logged in the Patient Request Log.

9.4. Ensure that an Access Request Form is compiled for each access request

9.5. Store the Patient Request Log and the Access Request Form in the Compliance Repository

10. Patients' Bill of Rights: PHI Amendments (Track="Essential")

 

10.1. Ensure that our Organization allows amendments to PHI except in the following cases:

1) the PHI was not created by us;

2) the PHI is excluded from access and inspection under applicable law

3) the PHI is accurate and complete

10.2. Ensure that you adequately train Workforce members that have responsibility for fulfilling PHI amendment requests:
 

10.2.1. Job titles must reflect this responsibility

 

10.2.2. Designated Workforce members must clearly understand the "due process" requirements of providing amendments (e.g. 60 day requirement unless an extension is asked for and obtained in writing).

 

10.2.3. If the amendment request is granted, the designated Workforce member processing the request is responsible for working with the patient to identify other healthcare stakeholders that may need to be notified of the amendment

 

10.2.4. If the amendment request is denied, the designated Workforce member must provide the patient the reason for denial in writing

 

10.3. Ensure each patient amendment request is signed, dated, and logged in the Patient Request Log.

 
10.4. Ensure that an Amendment Request Form is compiled for each amendment request

10.5. Store the Patient Request Log and the Amendment Request Form in the Compliance Repository

This is not an exhaustive list of our Agile Methodology's "Tracks" and "Chunks" but it is a representative sample that should help you make significant progress on your HIPAA compliance initiative in short order.

Tracking your HIPAA Compliance Initiative

We often write about the need to track your HIPAA compliance initiative at the granularity level of a requirement. Now with our FREELY available Scorecards you can do exactly that. However, to understand how to use our Scorecards you must first understand that we tie HIPAA compliance requirements to Checklist Items. And so that begs the question(s), from our perspective, what is a checklist generally and what are checklist items? Before we describe these abstractions please take note that at the heart of our compliance methodology is the following equation: 

 

policies + processes + tracking mechanisms = visible demonstrable evidence ("VDE") of compliance with a specific regulatory requirement.

 

HHS has published 169 "audit protocol" requirements that we map to Checklist Items. Currently our Scorecards allow you to track requirements for the HIPAA Privacy Rule and the HIPAA Security Rule. We also have Checklist Items for nuanced HIPAA requirements such as Cloud, Social Media, and Mobile. We are in the process of creating a scorecard for our Breach Notification Framework as well. As we have written about previously the regulatory requirements for Breach Notification are "a horse of a different color" and that is one of the reasons a scorecard for Breach Notification has lagged.

 

Ours Checklists are comprised of checklist items. In general, each checklist item contains the following: 1) a policy statement; 2) a definition of a process that underpins the policy; and 3) suggested tracking mechanism(s) to capture process results.  Checklist items will be named using the following convention:

• prefix name of the Rule (e.g. "PR" is short for the HIPAA Privacy Rule);
• followed by a dash;
• followed by the sub-segment of the PR (e.g. UD for uses and disclosures);
• followed by a dash; 
• followed by a four digit unique identifier;
• followed by the name of the checklist item.

For example, "PR-UD-0001 Violation" is the name of a hypothetical checklist item. We have broken down the PR into the following three sub-segments: 1) Uses & Disclosure ("UD"); 2) the Patient's Bill of Rights ("PBR"); and 3) the Administrative Requirements ("AR"). Progress on the Checklist directly correlates to progress on your Privacy Rule compliance initiative.

 

What is a Policy?

The word "policy" can be used in so many ways that it bears some exploration, especially regarding HIPAA regulatory compliance. We often talk of "developing a policy," or of "implementing a policy" or of "carrying out a policy." For example, 45 CFR §164.530 (i)(1)[3] states as follows:

Standard: Policies and procedures. A covered entity must implement policies and procedures with respect to protected health information that are designed to comply with the standards, implementation specifications, or other requirements of this subpart and subpart D of this part.

Notice that the standard above makes a distinction between policies versus procedures. In general, think of a "policy" as a purposeful set of decisions or actions usually in response to a problem that has arisen. From a compliance perspective, a policy is a set of statements, including decisions and actions regarding what an organization intends to do in order to meet its regulatory requirements (e.g. see ourBreach Notification Policy). A policy indicates what an organization intends

to do and is often also used as a communications vehicle of that intent.

 

What is a Process?

A process is a repeatable series of steps that are accomplished over time. From a HIPAA regulatory compliance perspective, processes are how policies get implemented. Policies without processes are nothing more than empty promises and will not prevent serious compliance liability. HHS will required evidence of policies and processes. For example, the Privacy Rule in section 45 CFR §164.530 (b)(1) states the training requirement as follows:

Standard: Training. A covered entity must train all members of its workforce on the policies and procedures with respect to protected health information required by this subpart and subpart D of this part, as necessary and appropriate for the members of the workforce to carry out their functions within the covered entity.

The requirement expressly states that the training must cover both your organization's policies with respect to the Privacy Rule and your underlying processes. Notice that nothing in the standard indicates how the required training should be carried out. The training standard has a corresponding implementation specification that reads as follows:

 

(2) Implementation specifications: Training.

(i) A covered entity must provide training that meets the requirements of paragraph (b)(1) of this section, as follows:

(A) To each member of the covered entity's workforce by no later than the compliance date for the covered entity;

(B) Thereafter, to each new member of the workforce within a reasonable period of time after the person joins the covered entity's workforce; and

(C) To each member of the covered entity's workforce whose functions are affected by a material change in the policies or procedures required by this subpart or subpart D of this part, within a reasonable period of time after the material change becomes effective in accordance with paragraph (i) of this section.

(ii) A covered entity must document that the training as described in paragraph (b)(2)(i) of this section has been provided, as required by paragraph (j) of this section.

Again, although the implementation specification speaks to when training is required and the fact that it must be documented, it does not prescribe how your training should be conducted. Your training process is the vehicle used to specify, with a degree of detail and rigor, how your training will be carried out (e.g. formal classroom training, audited video training, self help training, etc.).

 

What is a Tracking Mechanism?

A tracking mechanism is a way to keep track of process results. For example, QuickBooks is a tracking mechanism for accounting data and processes. You must be able to track the results of your compliance processes if you hope to provide visible demonstrable evidence that you are meeting regulatory requirements. Your HIPAA training policy indicates your compliance training intentions; your training process is how you go about fulfilling those intentions; and your tracking mechanism must capture the results of your training process (i.e. how well you did in meeting your intentions). HHS will likely want to see evidence of all three components, but if you cannot show process results, then your entire training initiative is likely to be suspect.

 

There are many compliance processes that require tracking (as discussed throughout this Checklist) including, but not limited to the following:

 

1)     patient privacy notice provisioning process;

2)     patient authorization process;

3)     patient restriction request process;

4)     patient complaint process;

5)     patient record access request process; and

6)     workforce training process.

 

This "short list" of processes is not exhaustive but rather illustrative of the scope and magnitude of what needs to be tracked in order to move your organization along the compliance continuum toward full compliance.

 

How should your compliance processes be tracked? It is no longer reasonable to track compliance processes on paper (if it ever was). You are going to need a suitable Intranet, spreadsheets, and/or software in order to track and report effectively. We recommend the latter because it is the most economically viable option, even for small covered entities and business associates.

 

 

Business Associates Everywhere!

We have written about business associates on previous occasions, notably here and here. If you want to get grounded in business associate basics we encourage you to peruse the previous links. This post focuses on the business associates as software vendors and the issues presented by this relationship from the perspective of the business associate.

 

In many case, where business associate software vendors ("Vendors") are dealing with small covered entities, then the Vendor is usually driving the relationship. Therefore, from a business associate agreement ("BAA") perspective, this tends to favor the Vendor for a number of reasons that we discuss next.  First, if the covered entity is signing the Vendor's BAA then the "nasty" issue of indemnification for breach does NOT come up for the obvious reason that the Vendor drafted the BAA. Other potentially burdensome issues, such as asking for veto power over the Vendor's subcontractors ("Subs") (now business associates if the Vendor shares PHI with its Subs) likewise do not arise.

 

However, all that changes if the covered entity ("CE") insists on having the Vendor sign its BAA. Now the Vendor will likely need to deal with not only indemnification but also potentially a host of other burdensome issues it may not have anticipated (e.g. the covered entity asking the Vendor to have, or obtain, cyberinsurance for a significant amount of coverage). 

 

Here's why the coverage will appear to be draconian. Assume that the Vendor experiences a Breach of 5000 patient records wherein it has to indemnify the CE. At $200 per patient (conservative because the Ponemon Institute estimates that it costs the healthcare industry over $300 per patient to notify). At the conservative estimate of $200 per patient a 5000 record Breach would cost a cool $1 million dollars in notification costs alone. With thumb drives and mobile devices now capable of holding millions of records a Breach of 100K records would be considered small. That would cost the Vendor $20 million dollars in indemnification costs.

 

In short, anything less that a $10 million policy is likely to be a waste of money. It's simply not nearly enough to cover the costs of even a relatively small breach. Because "cyberinsurance" is a new game in town, the insurers are struggling to develop competitive pricing. So, if you are looking for insurance, it pays to perform a significant amount of due diligence regarding premium prices and coverage.

 

Of course, the absolute BEST insurance is to encrypt ALL PHI according to the NIST protocols recommended by HHS. If the Vendor encrypts PHI as specified then there can be no Breach by definition because the PHI has been rendered unusable, unreadable, or indecipherable. The translation of which is that the bad guys can't do anything with it. That is a powerful argument to present to a CE as to why (perhaps) a much smaller amount of cyberinsurance is required.