The following is a guest article by Kate Barecchia, Global Data Privacy Officer at Imperva.
For many of us, change is hard. In cybersecurity, change is essential to defeat two of the most common causes of data breaches: the ever-evolving attack styles of hackers and human error. New products and features designed to protect data from the latest attack vectors and human errors are released regularly. While innovation is crucial to prevent data loss, there’s an understandable tension between the need to adopt new technology and the inherent risk any new technology brings.
It’s safe to assume that securing protected healthcare information (PHI) would be a top priority for healthcare IT and security professionals, even if HIPAA didn’t require it. Nonetheless, despite the hard work and vigilance of their IT and security teams, many healthcare organizations still experience data breaches. According to the U.S. Department of Health and Human Services, 40 data breaches involving PHI, contained in more than one million records, were reported in January 2023. Naturally, healthcare organizations want to avoid being on that list, as data breaches impact patients, bring negative publicity and loss of brand reputation, create a substantial drag on personnel, and can result in hefty fines.
In the healthcare industry, HIPAA provides an additional layer of risk management complexity. Generally speaking, IT and security professionals in other industries share the same desire to protect data. Unlike other industries, healthcare IT and security teams, along with their legal teams, face clear consequences of negative publicity, fines, and risk of reputation loss under HIPAA. That sometimes drives a legal team to adopt highly risk-averse positions with their vendors in negotiations for new technologies that can adversely impact the organization’s ability to onboard new technology.
Over time, these overly conservative risk positions can have an unintended negative impact on healthcare operations by stifling innovation and weakening an organization’s overall security posture. In support of their risk positions, we frequently see more conservative healthcare organizations relying upon the same HIPAA myths to support commercially tenuous or unreasonable contract requests. By challenging these myths as a trusted internal partner, the healthcare technical teams may be able to eliminate roadblocks on the path to modernization.
Myth 1. PHI Can Never Leave the United States
Many healthcare organizations want their vendors to host all data within the continental United States, and to provide support and services exclusively from the US. There is an understandable comfort level for the healthcare legal team to have the data remain within the United States, because the team is likely more familiar with US laws and the risks inherent in the ordinary course of business.
While some vendors may be able to offer hosting, support, and services only in the US, other vendors provide more cost-effective services using offshore resources. Nothing in HIPAA requires PHI to be stored in, accessed only from, or processed exclusively within the United States. If you are considering a vendor providing 24×7, 365 support, it’s likely that some support will be provided outside the United States to manage costs. That offshore support can still be HIPAA compliant.
When a negotiation becomes stuck over the non-existent requirement to have data reside exclusively within the United States because “it’s required by HIPAA”, I’ve found it effective to ask the healthcare legal team to cite the provision of HIPAA they believe supports their position. Because there is no provision they can cite, we can often move forward with negotiations. In some cases, however, the legal team has an established risk position that isn’t tethered to the actual legal requirements. Instead, it’s tied to a feeling of comfort. In those cases, it often takes internal business pressures to force the legal team to change course.
As the healthcare IT professional seeking to procure the vendor’s services, there are some useful tools to help advance negotiations that concern offshoring. For example, it’s possible to reduce the risk offshoring may bring by performing enhanced vendor screening to assess the controls the vendor has implemented. Obtaining contractual commitments about the technical and organizational measures the vendor has implemented, like multi-factor authentication (MFA), identity control, role based access limitations, de-identification, obfuscation techniques like hashing, and encryption can also be effective risk mitigation techniques. Another technique to manage this risk is to ask the vendor to provide third party attestations, like ISO 27001, SSAE18, or other audits performed by a reputable, accredited third-party agency.
Myth 2. HIPAA Requires Uncapped Indemnification
Indemnification terms in a contract define what happens when something goes wrong and provides a way to balance risk between the parties, before anything has actually gone wrong. For example, if a reportable security breach were to occur, indemnification terms might define who would bear the costs of outside counsel to advise on reporting requirements, who would pay for a notification or call center for impacted individuals, and who would pay for experts to conduct a forensic analysis of the attack.
Typically, indemnification terms include a limit of liability, which represents the maximum amount of money the indemnifying party would have to pay if something went wrong. Common commercial practice is to set the limit of liability at a multiple of the annual fees paid under the contract. So, as an example, if a customer pays $50,000 a year for a service, the vendor might set the limit of liability at 3x this amount, or $150,000. The practice of using multipliers for a limit of liability ties the vendor’s risk under the contract to the commercial value of the contract.
A few times a year, I encounter healthcare organizations that argue that HIPAA requires uncapped indemnification for any security incident. Essentially, the healthcare organization is asking for a blank check. In many cases, the healthcare organization wants the vendor to cover the costs of a security incident even if the security incident is caused by the healthcare organization. In today’s market, asking for a blank check or for no-fault liability can be especially challenging.
Over the past decade, the availability of cyber insurance coverage has dramatically decreased as claims and payouts have multiplied. At the same time, the likelihood of a security incident has increased, leading healthcare customers to want to shift more risk to their vendors. When this happens during a contract negotiation, it’s important to acknowledge that HIPAA doesn’t require that kind of risk shifting.
It can be hard as a non-lawyer to respectfully challenge a lawyer who is claiming to recite what the law requires. When this issue arises, a solid technique is to non-confrontationally ask if the lawyer can cite those provisions of HIPAA so the IT team can review them to make sure it has the appropriate risk management framework in place. Often, that can transform the situation from a compliance mandate into a commercial issue in which both IT and legal are stakeholders with decision input.
Myth 3. All Vendors are Business Associates and Must Enter a Business Associate Agreement
Over the years, I have represented a number of different companies who were software providers to the healthcare industry. During that time, many healthcare customers would open the conversation with a statement along the lines of: “We are a Covered Entity. Therefore, as a vendor, you are a Business Associate and you need to enter our Business Associate Agreement (BAA).”
In reality, a Business Associate is more narrowly defined by HIPAA as a person or entity that performs services for a Covered Entity that involve the use or disclosure of PHI. Often, healthcare companies take the approach that any software provider falls within this scope. However, many types of software don’t require access to or use PHI. For example, if a software is providing enterprise resource planning (ERP) functionality and accounting for the number of supplies, like N-95 masks or scalpels, in a hospital’s inventory, there is no PHI involved and the software vendor should not be required to enter a BAA. In contrast, if a vendor were providing a medical records system, a BAA would be entirely appropriate.
BAAs include HIPAA-required contract terms related to inspections by the Secretary of the United States Department of Health and Human Services, as well as other terms that impose burdens on a vendor. If those burdens aren’t required by law, it’s commercially reasonable for a vendor to want to avoid taking them on.
When a vendor challenges the need to enter a BAA, it can be helpful for the healthcare IT team to take a look at the data involved. If only log data is going to be used for support for an on-premises solution, would there be any PHI in the logs? In some cases, the answer might be yes, because the logs could contain the results of a returned query. In other cases, the answer might be no, because the logs might only contain IP addresses, globally unique identifiers (GUIDs), or hospital employee identifier information. Having accurate information about the data involved in the vendor relationship, and communicating that information to the healthcare legal team, can be an effective way to resolve the impasse.
In conclusion, HIPAA doesn’t have to stymy innovation. For leaders working in the US healthcare industry, particularly CIOs or CISOs, having strategies to combat common HIPAA myths in vendor negotiations can go a long way to reducing friction in the vendor onboarding process.
*The views in this article are solely those of the author and do not represent the views of Imperva. Additionally, while this article discusses legal topics, the author is not providing legal advice and the reader should consult their own counsel.
