To understand how different healthcare organizations are handling some of these sticky issues, privacy and compliance officers from Fortune 10 and Fortune 500 healthcare organizations joined participants at our recent RadarFirst User Summit Series to share ideas. Here are some of the things we learned.
How to Distinguish Between Privacy and Fraud When Handling Incidents
One of the complexities brought up by our panelists is how to distinguish between medical fraud and medical privacy incidents, and whether every incident of fraud should trigger a privacy incident risk assessment.
In practice, a privacy incident can certainly lead to fraud, when a stolen medical identity is used to obtain medical services, for example. But fraud can also happen without unauthorized exposure of PHI or PII.
Whenever fraud is detected, there needs to be a rapid investigation to determine whether there is also a privacy incident. The deciding factor is the source of the information used to commit the fraud. One panelist gave the example of a dishonest medical provider who sees a patient, then fraudulently bills for a same-day follow-up appointment that never happened. This wouldn’t necessarily be considered a privacy issue because the provider was leveraging information that they had legitimate access to for healthcare operation purposes.
Likewise, if a patient used their own insurance to go “pharmacy shopping,” trying to get pain med prescriptions filled multiple times, there would be fraud but no unauthorized exposure of PHI/PII.
If the fraud involved unauthorized use of data, the next question is the source of that data.
- Was it bought on the dark web?
- Was there a breach of your organization’s systems, or a third party’s systems?
It may be impossible to determine exactly where the data came from, but it’s important to verify that your organization was not the source.
One panelist said cases reported as fraud come into their organization’s special investigations unit (SIU) first. If SIU believes there has been a disclosure of personal information, they will refer the incident to the privacy team for investigation, assessment, and notification decisions. But it can be difficult to determine the true source of fraud because it can be one person’s word against another’s. (To use the pharmacy example, was there fraudulent billing by the pharmacy or pharmacy shopping by the insured?)
59 percent of session participants said their organizations always conduct a privacy risk assessment when fraud is reported, and 38 percent said they often or sometimes conduct privacy risk assessment in case of fraud.
The decision may ultimately be one of resources, risk tolerance, and the kinds of fraud that are most common in a particular organization. Whatever the policy, assessing the privacy aspects of medical fraud depends on close relationships and collaboration between the fraud investigation team, the data security team, and the privacy team.
And, if there is unauthorized access of personal information, it’s prudent to conduct a privacy risk assessment and document findings about why your organization is or is not the source of the information exposure.
Privacy Impacts of Ransomware Attacks
Ransomware attacks are another sticky wicket for healthcare privacy teams.
HealthITSecurity reports that there were 41 successful ransomware attacks on healthcare organizations in the first half of 2020, and one out of 10 ransomware attacks results in data theft.
85% of session participants said that their incident response plans address dealing with ransomware incidents.
The immediate need is to get critical medical systems back up and running, but in the aftermath of ransomware, the incident response team needs to know two things:
- Was there an actual data breach? In other words, did the attack actually involve data exposure, which may be unanswerable unless exfiltrated data shows up on the dark web or being used for fraud.
- Are there potential notification obligations triggered by the ransomware attack, regardless of whether data is known to have been exposed?
The data exposure question needs to be answered by a forensic investigation, often by the information security team or security operations center (SOC), looking at the environment affected by the ransomware attack, the data in that environment and whether it was encrypted or otherwise protected, the specific malware used, etc. As our panelists pointed out, this can be difficult to determine for sure, but the findings and conclusions need to be included in the incident response documentation.
Meanwhile, the privacy team can begin the regulatory assessment. In the U.S., OCR guidance says that a ransomware attack may be considered a breach under the HIPAA rules, even if data was not exfiltrated. So that guidance must be considered, along with any state laws that cover ransomware.
Download The Definitive Guide to Privacy Incident Response here >
Once the forensic investigation is complete, the privacy team needs to look at what data elements are involved in the attack and what notification requirements they may trigger under HIPAA or other regulations. For example, new insurance regulations in Virginia require notification to individuals affected by a cyber security incident such as a ransomware attack.
One of our session participants raised another challenge that stems from ransomware attacks: the high cost of response. The panelists agreed that, with the need for outside forensics and outside counsel, costs can run into $100K to $200K range. While some of these costs can be displaced through cyber liability insurance, there are other financial risks such as reputational damage that can’t be anticipated. So, prevention is definitely the most cost-effective approach to ransomware.
Profiling an Incident from the Perspective of a Business Associate or Processor
Another topic, raised by RadarFirst’s customer advisory board, was how to profile an incident in which your organization is operating in the role of a business associate or data processor, as opposed to a covered entity (CE) or data controller.
73 percent of session participants reported that their organization is profiled as the processor / third-party at least some of the time.
Our panelists stressed that the response process for these incidents needs to be the same as for any other incident, even if the organization is in the role of a third-party associate. Triage needs to happen quickly, because there may be contractual obligations to notify the CE or business partners, sometimes within hours. One panelist noted that short-turnaround notification is done by a dedicated team within the SOC.
Notification obligations can vary widely, depending on the business partner’s policies and risk tolerance. Some may require notification of all incidents, whereas others will want notification only if the case falls within regulatory definitions of a breach.
In general, though, the panelists agreed that notification timelines and requirements are becoming more stringent. Radar tracks third-party notification obligations and takes them into account when providing automated notification recommendations, helping to meet these stringent deadlines.
Learn how a Fortune 200 healthcare company cut incident risk assessment time by 50% with Radar >
How Do Privacy Teams Apply Notification Exceptions from U.S. State Laws?
A number of U.S. state laws exempt federally regulated entities from notification requirements when they meet federal notification requirements. These exemptions vary from state to state.
For example, Iowa grants a complete exemption from notification requirements where federal HIPAA requirements apply, whereas New York exempts from notification to affected individuals but still requires notification to the state Attorney General, department of state, state police, and consumer reporting agencies.
39% of session participants said that their organizations have a policy for applying state exemptions.
If an incident involves only HIPAA-regulated data, it’s comparatively straightforward to look at the applicable state laws and determine where to leverage partial or complete exemptions.
Panelists said it grows more complicated when the incident involves a mix of HIPAA and non-HIPAA-regulated data elements—for example, if there were also life insurance products involved. Privacy teams have to look at HIPAA and non-HIPAA exemptions in each state and determine how to apply both. Radar also helps automate this process, applying state law exemptions when risk assessing an incident.
When the data elements are mixed, complexity increases. And if an individual has both HIPAA and non-HIPAA elements involved (such as medical records and life insurance), the assessment has to determine all the exemptions that apply, then combine all those requirements to construct one notification per individual.
And it’s not just whether to notify, but what information to include. For example, Rhode Island requires notification to indicate how many individuals were impacted by a breach, whereas in Massachusetts, breach details can’t be included.
Preparation is Key
When it comes to the many complex questions of incident assessment, with regulations, business relationships, and risks in constant flux, you can prepare in multiple ways:
- To help you stay ahead of regulatory changes, you can take use Radar’s Global Data Breach Notification Law library, a free resource with hundreds of global privacy laws, rules, and regulations that’s kept current on both existing and proposed legislation.
- Keep an eye on new regulatory development, such as the model law for insurance data security published by the National Association of Insurance Commissioners (NAIC). These laws include a breach notification obligation component, and there are subtle differences in the requirements from state to state.
- Watch for trends, particularly when it comes to ransomware
- Try to have a variety of policies, processes, and tools in place for emerging needs
- Use tabletop exercises to practice for the more complex or unusual scenarios.
The better you can anticipate, the more successfully you’ll handle those privacy incidents when the time comes.