September 01, 2017

Tips for Negotiating Business Associate Agreements with Health IT Vendors

Jordan A. Stivers, Bradley Arant Boult Cummings LLP, Nashville, TN

When healthcare providers contract with health IT vendors for products and services such as an electronic health records (EHR) system, cloud hosting services, or connected devices, the vendor will most likely become the provider’s “business associate” under the Health Insurance Portability and Accountability Act of 1996 (HIPAA).1 HIPAA requires covered entities and business associates to enter into a business associate agreement (BAA) that outlines the responsibilities of each party to ensure that patients’ protected health information (PHI) is secure.2

Negotiating the BAA often becomes a “battle of the forms,” with each party insisting on using its own form BAA. When the vendor’s form is used, providers often do not negotiate to include provisions that will provide them adequate protection in the event of a breach, because either they do not believe they have enough leverage or because they want to ensure that the contract is signed quickly. However, it is critically important that the BAA address the risks that each party is assuming. When a breach occurs, the BAA will dictate the duties each party has in responding to the breach, including which party is responsible for the costs of notifying affected individuals and government agencies, legal fees, providing a toll-free number for information regarding the breach, and providing credit monitoring services to affected individuals.

Having a BAA that contemplates the risks to PHI and each party’s role in managing those risks is especially important in a transaction with a health IT vendor. Health IT products and services typically involve large quantities of electronic PHI (ePHI) and other sensitive information, and with the recent surge in ransomware and other cybersecurity attacks targeting the healthcare industry, BAAs should cover both prevention and mitigation of security incidents and breaches. The following are some issues to keep in mind when negotiating a BAA with a health IT vendor.

Substance > Form

It is important to focus more on the content of the BAA rather than which party’s form is used, especially if the provider is smaller and has less leverage than the health IT vendor. Every organization’s form BAA should contain the standard provisions required by HIPAA,3 and providers may wish to agree to use the vendor’s form BAA since the vendor may then be more inclined to negotiate in a few key provisions that are important to the provider, such as responsibility for the costs of a breach, encryption standards, or no-offshoring of the provider’s PHI.4 Negotiating any agreement involves give and take, and by agreeing to use the vendor’s form, the provider will start off the negotiations with a concession that will provide some room to request the revision, addition, or deletion of certain provisions.

Tailor the BAA to the Level of Risk

It is not wise to take the same approach to every BAA with a health IT vendor. While the standard HIPAA-required provisions must be in each BAA, other risk allocation provisions may be necessary to include depending on the level of risk associated with the underlying agreement. In general, the level of risk varies depending on the type and amount of PHI being created, received, maintained or transmitted by the vendor pursuant to the underlying agreement for the health IT product or service. When there is a significant amount of PHI involved, or the PHI involved is of a particularly sensitive nature, the BAA should be tailored to require extra layers of protection. On the other hand, if there is only a minimal amount of PHI involved, or if the vendor will only be incidentally exposed to PHI, demanding provisions that are too stringent may be met with a refusal by the other party to negotiate at all, and the transaction may be stalled. The extent to which a health IT vendor will be willing to negotiate the provisions of the BAA often depends on the amount of leverage each party has, due to the party’s size or the value of the contract.

Address Issues Specific to Health IT in the BAA

Data Analytics

Data analytics, also known as “big data,” is becoming increasingly utilized in the healthcare industry. The purpose of data analytics is to assess individual patients within the context of a larger population to more easily identify, treat, and prevent illness. Data analytics works by applying machine learning and artificial intelligence to large amounts of health information to identify patterns and similarities, so that healthcare information is no longer confined to the individual healthcare entity that created it.

Many health IT vendors that offer various products and services such as EHR systems, cloud-based software, etc. also have the capability to perform data analytics using the PHI they create, receive, maintain or transmit on behalf of healthcare providers as a business associate. In a BAA with such a vendor, healthcare providers should address whether and to what extent the vendor is permitted to use the provider’s PHI for data analytics. Providers should be aware that some common provisions in BAAs may be interpreted to allow a business associate to use PHI to perform data analytics, such as those permitting data aggregation, de-identification of PHI, and uses and disclosures of PHI for the management and administration of the business associate. Providers may wish to clarify in the BAA whether and to what extent the business associate will be permitted to use the provider’s PHI when performing data analytics, and not leave it open to interpretation.

Cloud Computing

In 2016, the U.S. Department of Health and Human Services’ Office for Civil Rights (OCR) issued guidance on HIPAA and cloud computing to address the “proliferation and widespread adoption of cloud computing solutions” by healthcare providers and other entities in the healthcare industry.5 The guidance clarified that even cloud services providers (CSPs) who provide “no-view services” (meaning that the information stored in the cloud is encrypted and the CSP does not have the decryption key) are business associates under HIPAA. The guidance makes clear that if a covered entity or business associate uses a CSP to maintain (e.g., to process or store) ePHI without entering into a BAA with the CSP, it is in violation of HIPAA.6 Last year OCR entered into a resolution agreement for $2.7 million and a corrective action plan with a covered entity that stored the ePHI of over 3,000 individuals on a cloud-based server without entering into a BAA with the CSP.7

OCR advises that a covered entity or business associate that engages a CSP should understand the cloud computing environment or solution offered by the particular CSP so that it can appropriately conduct its own risk analysis and establish risk management policies, as well as enter into appropriate BAAs that address the specific risks presented by the cloud computing environment. For example, one aspect of the cloud computing environment that providers should pay particular attention to is whether their data will be commingled with other customers’ data, making it more likely to be compromised. Providers may wish to address this by inserting a provision in the BAA requiring that its ePHI be segregated from other customers’ information.

Cyber Liability Insurance

Increasingly, providers are requiring business associates who are health IT vendors to maintain a certain level of cyber liability insurance, and to provide a certificate of insurance to the covered entity every so often to confirm that such insurance is in place. There are variations depending on the specific policy, but cyber liability insurance generally covers costs associated with responding to a data breach, such as the cost of a forensic investigation, legal advice to determine notification and regulatory compliance obligations, notifications to affected individuals and applicable government agencies, the cost of offering credit monitoring to affected individuals, public relations expenses, and loss of profits resulting from business interruption.

Limitation of Liability

Many underlying agreements with health IT vendors have a provision limiting the vendor’s liability to the amount of fees the provider has paid to the vendor within the 12-month period preceding the event giving rise to the liability. Covered entities might consider requesting a provision in the BAA that states that any limitation of liability in the underlying agreement does not apply to the vendor’s liability stemming from a data breach.

Conclusion

When entering into a BAA with a health IT vendor, providers should consider the unique privacy and security issues with health IT products and services, and ensure that the BAA sufficiently addresses the specific risks involved in using the technology. Addressing these matters from the outset will help prepare both parties to better prevent and mitigate threats to the privacy and security of ePHI. 

  1.  See definition of “Business Associate” at 45 C.F.R. § 160.103; See also OCR’s guidance on Business Associates (found at: https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html); In its guidance on Cloud Computing (found at: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html) and health information exchanges (found at: https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/index.html), OCR states that when a covered entity engages the services of a health IT vendor to create, receive, maintain, or transmit ePHI on its behalf, the health IT vendor is a business associate under HIPAA.
  2.  45 C.F.R. § 164.502(e)(2); 45 C.F.R. § 164.504(e).
  3.  OCR’s sample BAA provisions may be found at: https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html.
  4.  “Off-shoring” refers to the practice of storing or processing information at data centers overseas.
  5.  OCR’s Guidance on HIPAA & Cloud Computing (found at: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html).
  6.  Id.
  7.  OCR Resolution Agreement with Oregon Health and Science University, July 18, 2016 (found at: https://www.hhs.gov/sites/default/files/ohsuracap_508.pdf).

Jordan A. Stivers, Bradley Arant Boult Cummings LLP, Nashville, TN

Bradley Arant Boult Cummings LLP

Jordan Stivers is a healthcare and privacy/cybersecurity attorney with Bradley Arant Boult Cummings LLP in Nashville, Tennessee. She assists clients in the healthcare industry in regulatory, operational, and transactional matters. In particular, she advises healthcare providers, including hospitals, ambulatory surgery centers, and physician practices on HIPAA and HITECH compliance, day-to-day privacy and security operational issues, and data breach response. She has assisted clients in drafting, reviewing, and negotiating business associate agreements and other healthcare technology agreements, as well as privacy policies and procedures. Ms. Stivers is a Certified Information Privacy Professional (CIPP/US). She may be reached at jstivers@bradley.com