Though the minimum requirements for the content of a Business Associate Agreement (BAA) are mandated by the HIPAA regulations (45 C.F.R. §164.504), there is still a lot to think about when reviewing a BAA. This article aims to shed light on some of the often-overlooked areas of concern from both the position of a Covered Entity and a Business Associate, then highlights some issues that both parties may wish to consider.

Covered Entities will want to be thoughtful of the following tips:

HIPAA requires Covered Entities to conduct standard transactions with one another. Conducting a transaction as a “standard transaction” includes compliance with the set data standard and affiliated operating rules, code sets, and unique identifiers for the particular transaction. Specific parameters for Covered Entities also exist. For example, if a Covered Entity uses a Business Associate to conduct any portion of a transaction for which a standard has been adopted, the Covered Entity must require its Business Associate (and its agents and subcontractors) to comply with that standard. Simply put, the inclusion of a Business Associate in a transaction does not relieve a Covered Entity of its responsibility to comply with HIPAA because a Business Associate is acting on behalf of a Covered Entity. As such, if the Business Associate will be performing any portion of a standard transaction it is a good idea to contractually obligate the Business Associate to comply with ETS. For example: “Business Associate, along with its Workforce and Subcontractors, shall comply with all applicable electronic transactions and code sets standards under HIPAA.”

Because the “sale” of PHI is generally prohibited under 45 CFR §164.502(a)(5)(ii)(A) and “sale” is defined very liberally to include any “direct or indirect remuneration from or on behalf of the recipient” of the PHI, it is important to check the underlying service contract and deal terms to ensure that your organization is not receiving discounted pricing, free equipment, or more favorable terms than other entities because it is sharing PHI with the vendor. Additionally, while not required, it is generally a good idea to specify in the BAA that aggregation and de-identification of the data are not permitted uses under the agreement. On occasion, a Business Associate will reference the underlying service agreement in terms of permitted uses and later argue that aggregation and/or de-identification of the PHI was in some way necessary to perform the services. (The service agreement may even state this, so it is always a good idea to read BAA associated agreements carefully.) However, once PHI has been de-identified, it is no longer PHI and so is no longer protected by HIPAA!

The Business Associate should notify the Covered Entity of requests by patients for their records in a relatively short period of time. While HIPAA currently allows 30 days for a Covered Entity to respond to medical records requests, some states have medical records laws with shorter response periods (e.g., in Texas it is 15 days) and the much-anticipated update to the HIPAA regulations promises to shorten the 30 days to 15 anyway. Furthermore, the Business Associate might not realize that not all Covered Entities have a medical records department. Some rely on third party records management vendors for the processing of medical records release requests, so the more time the Covered Entity has to get the request to its vendor, which may subject its timely performance to mandatory request submission time-frames, the more likely the Covered Entity is likely to remain in compliance.

In addition to the general requirements of the Security Rule, a Covered Entity may wish to set more specific and stringent standards by which the Business Associate must protect the PHI. Why? Because your organization may be subject to state or federal laws with additional or more stringent data protection requirements. But even if it is not, a lot has changed in the tech world and in particular with cybersecurity since the HIPAA regulations last received a major update in 2013. And though the HITECH Act was amended in 2021 so that the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) will now consider the efforts of an entity made with respect to security when making determinations in its investigations of complaints and data breaches, the amendment did not create a safe harbor for HIPAA-regulated entities that have implemented industry-standard security best practices. In order to reduce the risk to patients' privacy and to your organization’s reputation and finances, having stronger cybersecurity requirements than those mandated by law is a very good idea.

While audit language is not required by the Code of Federal Regulations, Covered Entities will often add audit language to a BAA so that they have a means of assuring that their Business Associate is actively in compliance with the BAA. This is particularly important where the Covered Entity has cause to believe that the Business Associate may not be abiding by the terms of the BAA, but can’t prove it without an audit. Notably, however, if you do choose to include audit language it is generally a good idea to specify that such right in no way lessens the Business Associate’s obligations under the BAA, that your organization has no affirmative obligation to conduct such an audit, and that choosing not to exercise its right to audit shall not be construed as negligence should there be a breach.

Business Associates would do well to consider the following tips:

Uses of PHI not specified in a BAA are, unless otherwise required by law, prohibited. As such, don’t rely on a missing prohibition against data aggregation or mention of data aggregation in your underlying service agreement as permission if you need to aggregate the PHI in order to provide a contracted for service to the Covered Entity. It needs to be expressly granted in the BAA. Best practice is to explain to the opposing counsel why you need the ability to aggregate PHI, and negotiate language that permits such aggregation.

As mentioned above, many times a Covered Entity will want to use its paper in negotiating a BAA and you may find that there are no contractual obligations for the Covered Entity. It is generally a good idea to add the following obligations, to ensure that your organization can meet its own under the contract:

(i) Notice of Privacy Practices (NOPP) – The Covered Entity should notify the Business Associate of any limitations in its notice of privacy practices as well as any that may affect the Business Associate’s use or disclosure of PHI, and the Business Associate should consider adding a clause permitting it to terminate the BAA in the event changes to the NOPP materially and adversely impact its operations.

(ii) Notice of Changes in Individual Permission – Similarly, the Business Associate should be notified by the Covered Entity of any changes in or revocation of any individual’s permission to use or disclose his or her PHI that may affect the Business Associate.

(iii) Notice of Further Restrictions – The Covered Entity should also notify the Business Associate of any restriction to the use or disclosure of PHI that the Covered Entity has agreed to, in accordance with 45 C.F.R. 164.522, if it might affect the Business Associate.

(iv) Permissible Requests by Covered Entity – Finally, it is recommended that the Business Associate include language obligating the Covered Entity to not request it to use or disclose PHI in any manner that wouldn’t be permissible under HIPAA if done by the Covered Entity, with the exception of permitted data aggregation or management and administrative activities. This provides the Business Associate some protection in the event the Covered Entity’s personnel attempt to instruct the Business Associate to disclose or use PHI for an impermissible reason.

Some Covered Entities will prohibit the use of subcontractors by their Business Associates, but it is always best to negotiate in some flexibility, if possible, in the case the Business Associate wishes to expand its services without expanding its workforce. A reasonable alternative to the prohibition on subcontractors is language stating the Business Associate shall ensure that any third-party agents, including subcontractors, that create, receive, maintain, or transmit electronic PHI on behalf of the Business Associate agree to enter into a contract or other arrangement that complies with 45 C.F.R. § 164.314.

If possible, steer clear of language broached by the Covered Entity requiring the Business Associate to (a) notify the Covered Entity of all subcontracts and agreements relating to the BAA where the subcontractor or third-party agent receives PHI as described in the BAA within a set period of time from the execution of the subcontract; (b) provide such subcontracts to the Covered Entity upon request; or (c) flow down exactly the same obligations to the subcontractor as those of the Business Associate in the BAA. You do not want the administrative headache of making such notifications, nor should the Covered Entity be entitled to see any un-redacted contracts with your organization's subcontractors, which constitute confidential business information. Finally, you should only be obligated to flow down the relevant provisions of the BAA to the subcontractor, particularly those around physical, technical, and administrative safeguards. The subcontract need only comply with 45 C.F.R. §164.314 and mandating the exact terms with respect to all of the provisions will significantly hamper the Business Associate’s ability to negotiate with its subcontractors, especially as not all of the same obligations would apply.

It is important to avoid allowing a Covered Entity to over-specify the measures that your organization takes beyond those dictated by law. This is for a number of reasons: (1) your organization may not have in place all of the requirements that the Covered Entity demands; (2) the nature of your organization’s operations may not permit it to undertake differing security measures across clients, meaning that it has to utilize the most restrictive security requirements across all client data. As such, provided that your organization’s security meets an applicable third-party certification standard, specific security measures dictated in the BAA should be avoided. Along those lines, it is helpful to ensure that the contract includes contact information for the Covered Entity in the event your organization needs to notify it of a breach.

While audit language is not required by the Code of Federal Regulations, Covered Entities will often add audit language so that they have a means of assuring that their Business Associate is actively in compliance with the BAA. If possible, and you are not under a time crunch, a first response to such a provision would be to revise it such that in lieu of audit rights your organization promises to conduct annual third-party certification audits (such as Hi-Trust) and provide, upon request, a copy of such audit report subject to an applicable confidentiality agreement (or a redacted version of the report). If the Covered Entity insists on audit rights, it is important to limit audit frequency, scope, duration, purpose, and specify that costs shall be paid by the Covered Entity. A less favorable, more mutual provision would allow for an audit no more than once per year and during business hours, unless the Covered Entity is given cause (e.g., due to a breach) to audit your organization in the interim, where audit costs are to be paid for by the Covered Entity unless the audit is for cause and reveals that the Business Associate is non-compliant, in which case the costs are to be borne by the Business Associate.

It can be important for both parties to consider the following issues:

Do the definitions in the BAA merely cite to the relevant definition in the regulation or are they written definitions that might not accurately reflect the regulation? This is particularly important in regard to the terms “de-identification” and “data aggregation”. Why? Because these days data is extremely valuable, a Business Associate may wish to convert the PHI to its own uses through de-identification, however the regulation is very explicit as to what does and does not constitute a valid means of de-identifying PHI. Additionally, it is important that “breach” is correctly defined so that it is consistent with the term used in the regulation. This is because there can be multiple lay definitions of what constitutes a "security incident" and a "breach,” but the parties need to be sure about when the Business Associate should be notifying the Covered Entity and when they should comply with the Breach Notification Rule. Because it can be challenging to determine if a written definition of a term is a correct reflection of the regulation, which extends the time necessary to review and negotiate a BAA, where possible we suggest merely citing to the location of the definitions in the regulations for reference.

Under certain circumstances both a BAA and a Data Use Agreement (DUA) may be necessary, in which case they can be combined into a single agreement. LegalOn’s BAA offers this optional DUA language, so where appropriate your client need not enter into two separate agreements.

The HIPAA Security Standards, specifically 45 CFR § 164.314(a)(2)(C), require that a Business Associate report to the Covered Entity any security incident of which it becomes aware and “security incident” is defined by the HIPAA regulations to include attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system, not just those attempts that are successful. This can be an arduous obligation for both parties as certain attacks are likely to take place on a routine basis and the frequency of delivering and reviewing such notices can become overburdensome. As such, language minimizing the obligation to report unsuccessful security incidents that are likely to be routine (e.g., pings and other broadcast attacks on the Business Associate's firewall, port scans, unsuccessful log-ons attempts, and denials of service) is important from an operational standpoint for both parties. Here’s an example of such a limiting provision:

“Business Associate will also report the aggregate number of unsuccessful Security Incidents of which Business Associate becomes aware, provided that (a) such reports will be provided only as frequently as the parties mutually agree, but no more than once per month; and (b) if the definition of “Security Incident” under the HIPAA Security Standards is amended to remove the requirement for reporting “unsuccessful” attempts to access, use, disclose, modify, or destroy ePHI or interference with system operations in an information system, the portion of this Section requiring the reporting of unsuccessful Security Incidents will no longer apply as of the effective date of such amendment.”

For both parties it is important to consider whether the manner in which the BAA is drafted could create an agency relationship between the parties, resulting in potential vicarious liability for Covered Entities based their Business Associates’ misconduct or Business Associates for their subcontractors’ violations if such actions are within the scope of their agency. There are a number of factors that may evidence agency in a BAA, but some examples include: (a) language establishing that the Covered Entity (or Business Associate, if the other party is a subcontractor) has a right to give interim instructions and direction to the other party during the course of the relationship; (b) whether the Covered Entity or Business Associate delegates a particular obligation under the HIPAA Rules to its Business Associate or subcontractor; (c) the nature of the services provided by the Business Associate; and (d) whether the Covered Entity is prohibited from providing the service. It may also be helpful to review a BAA with the federal common law of agency in mind.

Generally, the Covered Entity will want to ensure that the BAA prevails over any related service agreement should there be a conflict or inconsistency between their terms. Conversely, the Business Associate may want the service agreement to prevail, particularly as it is more likely to be the Business Associate’s template and contain limitations of liability, which it can then construe to also apply in respect to its obligations under the BAA.