Interoperability and Business Associates

By William O’Toole, Founder, O’Toole Law Group
Twitter: @OTooleLawHIT

To BA or not to BA? When a covered entity contracts with two vendors for interface software between the vendors’ systems each vendor is a business associate of the covered entity, no different than before the interface project. However, the interface project does not itself create a subcontractor or any other contractual relationship between the two software vendors and does not require a business associate agreement between vendors. Unfortunately the requirements and exceptions for business associate agreements are often not understood. Guidance and clarification are essential.

Real world example:
Covered entity (CE) is implementing interfaces between Vendor A (my client) and Vendor B. Note there is no underlying agreement between Vendors A and B. The CE wants interoperability plain and simple and properly executed a business associate agreement (BAA) with each vendor. However, Vendor B gave CE a subcontractor business associate agreement (Sub BAA) between Vendor B and Vendor A, and told CE to have Vendor A sign it as the subcontractor in order to proceed with the project. I advised Vendor A not to sign the Sub BAA because it was not appropriate to the situation.

The CE and Vendor A had Vendor B authoritatively telling them what to do, and me advising them the opposite. Vendor B clamored that because its system feeds protected health information (results) to Vendor A’s system, Vendor A is its subcontractor. Surprisingly, when I asked for the (non-existent) underlying agreement between Vendor B and Vendor A, it made zero difference. More incredulous was the utter absence of recognition on Vendor B’s part that their system would be the first to receive protected health information, after which it would transmit updated results back to Vendor A’s system. The CE was miserable and concerned after hearing “Vendor A won’t protect protected health information as required by HIPAA.” My negative take on it is that Vendor B was muscling a (perceived) protection for itself or had not adequately researched and positioned itself in the context of the law, neither of which is acceptable.

Sadly, it is fair to predict that in a breach situation involving interfaces and a bogus stand alone Sub BAA, the “non-subcontractor” vendor will claim it is protected financially due to an indemnification provision in the Sub BAA, a grotesque but entirely possible scenario.

Business associates are agents of the CE, contracted to perform certain services for the CE, and accordingly a BAA is required. The difference in the situation above is that neither business associate is an agent of the other. There is no underlying services (subcontractor) agreement between the two software vendors. Consequently neither can be a business associate or subcontractor to the other. Each vendor is independently performing under its agreement with CE.

Accompany the software contract chain with business associate agreements. If there are a series of contracts associated with the transmission of protected health information, such as between CE and Vendor X and also between Vendor X and Vendor Y (contracted to perform services for Vendor X relating to the contract between CE and Vendor X), then CE and Vendor X must execute a BAA and Vendor X and Vendor Y must execute a Sub BAA with Vendor Y as subcontractor. However, if the software contract chain stops at Vendor X, so does the BAA chain.

My proposal? The following guidance should be provided by the Office of Civil Rights, consistent with guidances given for covered entities, health plans, and insurers:

Proposed OCR Guidance:
Other Situations in Which a Business Associate Contract Is NOT Required.
Interoperability. When multiple business associates of a common covered entity are software vendors that provide interface software to satisfy covered entity’s interoperability requirements per the terms of their respective and separate underlying services agreements with the covered entity. Each business associate is simply acting on its own behalf as a business associate to the covered entity, and not as the “subcontractor business associate” of the other(s).

Existing OCR Guidances:
Other Situations in Which a Business Associate Contract Is NOT Required.

  • When a health care provider discloses protected health information to a health plan for payment purposes, or when the health care provider simply accepts a discounted rate to participate in the health plan’s network. A provider that submits a claim to a health plan and a health plan that assesses and pays the claim are each acting on its own behalf as a covered entity, and not as the “business associate” of the other.
  • Where one covered entity purchases a health plan product or other insurance, for example, reinsurance, from an insurer. Each entity is acting on its own behalf when the covered entity purchases the insurance benefits, and when the covered entity submits a claim to the insurer and the insurer pays the claim.

The unease and lack of clarity on the part of Health IT vendors, providers, consultants, and attorneys in these situations is costly and concerning. Two Vendor A executives and I participated in a conference call with at least six (6) lawyers and executives representing CE and Vendor B, all strongly proclaiming their position as correct, despite my input and the lack of any specific official supporting guidance from Washington for their (inaccurate) position. In the end, two vendors and one provider incurred legal fees and corporate costs and made no headway.

We dug in and delivered the message that Vendor B’s demand was inappropriate and without sound basis, and that Vendor A would not sign the Sub BAA. The measurable discomfort on the part of CE and Vendor A was completely unnecessary, as was the considerable time spent by lawyers and executives. Fortunately, days later Vendor B reported that upon further review they agreed with our position.

Clarification from Washington, DC on this matter is important and will prove extremely beneficial to vendors and providers alike, as well as those that advise such entities, as we strive to meet interoperability mandates. CE heard opposing opinions from multiple lawyers, which left them searching for the correct answer.

Interoperability has ignited strong support and some vendor outcry; we all must contribute within our areas of expertise to help eliminate obstacles.

This article was originally published on O’Toole Law Group and is republished here with permission.