Hipaa Frameworks 12 Point Notification Flowcharts

Our Breach Notification Framework provides a step-by-step methodlogy that allows an organization to determine when HITECH / HIPAA Breach Notification is triggered. We educate our customers regarding how they should approach this important HITECH / HIPAA requirement and provide tools that help jump start your Breach Notification compliance initiative.



Decision Point: Flowchart 1 represents the first decision that must be made in order to determine whether or not an incident that may require HITECH Breach Notification analysis is “in play.” If the information system impacted does not contain PHI then HITECH Breach Notification cannot  be triggered by definition,  although other laws may still be applicable.

Decision Point: Flowchart 2 represents a critical question that must be asked regarding any breach or attempted breach. If the PHI in question has been secured (i.e. encrypted) according to the regulations then Breach Notification is not triggered by definition, because the PHI has been rendered unusable, unreadable or indecipherable to unauthorized individuals.

Decision Point: Flowchart 3 represents a more “real world” analysis that must be conducted to determine whether or not PHI has been secured appropriately. The analysis depends on the “state of the PHI” when it was allegedly compromised and whether or not certain NIST standards have been met or exceeded rendering the PHI unusable, unreadable or indecipherable to unauthorized individuals.

Decision Point: Flowchart 4 represents the analysis of another critical question regarding the allegedly comprised PHI. If there was no violation of the HIPAA Privacy Rule then Breach Notification is not triggered by definition. In other words, if the PHI was “used or disclosed” in a manner permitted by the Privacy Rule then the analysis stops, no further action is required other than completing the requisite documentation. This is a “common sense” analytical step that should not be skipped.

Decision Point: Flowchart 5 basically asks the same question as Flowchart 4 in a slightly different way. The real question, as we shall see in Flowchart 6, is much more complex and requires a dissection of the Privacy Rule in order to explore a reasonable answer. There are simply no “bright lines” formulas that provide easy answers regarding potential Privacy Rule violations, it all depends on the facts surrounding the security incident in question.

Decision Point: Flowchart 6 represents a subset of the Privacy Rule analysis required to determine whether the “use or disclosure” in question is permissible. The analysis starts with §164.502 Uses and disclosures of protected health information: general rules. Also, under HITECH Act §13404, covered entities may require business associates to comply with substantially similar requirements. Code Green refers to a Framework “scenario.”

Decision Point: Flowchart 7 represents a Framework “scenario analysis” to determine whether or not a Privacy Rule violation has occurred. In this case the PHI in question was purportedly de-identified information. The question is whether the appropriate de-identification process was followed as per the Privacy Rule? If so, then perhaps no violation occurred and therefore Breach Notification would not be triggered. Practices are encouraged to develop their own “scenarios” as they garner additional experience analyzing security incidents.

Decision Point: Flowchart 8 depicts the “notification flow” of security incidents. An incident may originate either with a business associate or internal to a covered entity’s operations. In the case of the former, covered entities and business associates need to establish a joint communications plan that will facilitate the business associate providing the covered entity the information that it needs to notify other stakeholders. As the chart indicates, only the covered entity is responsible for updating HHS, patients, and the media (if required).

Decision Point: Flowchart 9 depicts the conditions that must exist before Breach Notification is triggered. The conditions depend on the answers to the questions posed by the Framework’s methodology.  Only if the three conditions above are established is notification required. In the other words, if the use was permissible, or an exception applies, or the risk of harm threshold was not exceeded, then notification is not triggered. It is imperative that the analysis related to each question be captured in the Incident Document for subsequent internal/external reporting.

Decision Point: Flowchart 10 depicts various patient notification alternatives depending on the attributes of patient contact information that the covered entity has in its possession. The appropriate notification alternative also depends on the number of patients  with said attributes. The decision to be made here is how best to contact individuals after a breach, based on the best information available  to the covered entity.

Decision Point: Flowchart 11 depicts the State and/ or jurisdictional analysis required to determine when prominent media needs to be notified. Media only needs to be notified if the number of individuals in a State or jurisdiction exceeds 500. The Framework provides a sample press release to be used for media notification. The information provided to media is substantially the same as the information provided to individuals.

Decision Point: Flowchart 12 depicts the analysis required to determine when HHS is to be notified. The determination of when to notify HHS is dependent on the number of individuals impacted. Whenever the number of individuals impacted is 500 or more then the notification to HHS is required to be “without unreasonable delay” and no later than 60 days after the discovery of the breach. A breach impacting 500 or more individuals results in a posting on HHS’ website, otherwise known as “the wall of shame.”

Thanks for reviewing our Framework. Here's a FREE copy of Securing PHI Basics which is also included in our product.