Yesterday’s listserv announcement from the Office for Civil Rights (OCR) within the U.S. Department of Health and Human Services (HHS) brought to mind this question. The post announces the agreement by a Florida company, Advanced Care Hospitalists PL (ACH), to pay $500,000 and adopt a “substantial corrective action plan”. The first alleged HIPAA violation? Patient information, including name, date of birth, and social security number was viewable on the website of ACH’s medical billing vendor, and reported to ACH by a local hospital in 2014.

To add insult (and another alleged HIPAA violation) to injury, according to the HHS Press Release, ACH did not have a business associate agreement (BAA) in place with the vendor, Doctor’s First Choice Billings, Inc. (First Choice), during the period when medical billing services were rendered (an 8-month period running from November of 2011 to June of 2012). Based on the HHS Press Release, it appears that ACH only scrambled to sign a BAA with First Choice in 2014, likely after learning of the website issue. In addition, according to the HHS Press Release, the person hired by ACH to provide the medical billing services used “First Choice’s name and website, but allegedly without any knowledge or permission of First Choice’s owner.”

These allegations are head-spinning, starting with those implicating the “should’ve-been” business associate. First, how does a medical billing company allow an employee or any other individual access to its website without its knowledge or permission? Next, shouldn’t someone at First Choice have noticed that an unauthorized person was posting information on its website back in 2011-2012, or at some point prior to its discovery by an unrelated third party in 2014? Finally, how does a medical billing company (a company that should know, certainly by late 2011, that it’s most likely acting a business associate when it performs medical billing services), not realize that individually identifiable health information and social security numbers are viewable on its website by outsiders?

ACH’s apparent lackadaisical attitude about its HIPAA obligations is equally stunning. What health care provider engaged in electronic billing was not aware of the need to have a BAA in place with a medical billing vendor in 2011? While the Omnibus Rule wasn’t published until January of 2013 (at which point ACH had another chance to recognize its need for a BAA with First Choice), HHS has been publishing FAQs addressing all kinds of business associate-related issues and requirements since 2002.

It seems pretty obvious that ACH should have had a BAA with First Choice, but, in many instances, having a BAA is neither required by HIPAA nor prudent from the perspective of the covered entity. A BAA generally is not necessary if protected health information is not created, received, maintained or transmitted by or to the vendor in connection with the provision of services on behalf of a covered entity, business associate, or subcontractor, and having one in place may backfire. Consider the following scenario:

*          Health Plan (HP), thinking it is acting out of an abundance of HIPAA caution, requires all of its vendors to sign BAAs.

*          Small Law Firm (SLF) provides legal advice to HP, but does not create, receive, maintain or transmit protected health information in connection with the services it provides on behalf of HP.

*          However, SLF signs HP’s BAA at HP’s request and because SLF thinks it might, at some point, expand the scope of legal services it provides to HP to include matters that require it to receive protected health information from HP.

*          SLF suffers a ransomware attack that results in some of its data being encrypted, including data received from HP. It reviews HHS’s fact sheet on Ransomware and HIPAA, and realizes that a HIPAA breach may have occurred, since it cannot rule out the possibility that it received protected health information from HP at some point after it signed the BAA and prior to the attack.

*          SLF reports the attack to HP as per the BAA. Neither SLF nor HP can rule out the possibility that protected health information of individuals covered by HP was received by SLF at some point and affected by the attack.

HP is now in the position of having to provide breach notifications to individuals and HHS. Had it been more circumspect at the outset, deciding it would only ask SLF to sign a BAA if/when SLF needed protected health information in order to provide legal services on behalf of HP, it may have avoided these HIPAA implications completely.

So while it seems stunning that a health care provider entity such as ACH would have neglected to sign a BAA with First Choice before 2014, having a BAA in place when it is not necessary can create its own problems. Better to constantly ask (and carefully consider): to BAA or not to BAA?

Michael J. Coco writes:

The expanded requirements under the HIPAA Omnibus Rule for a Business Associate Agreement (“BAA”) has created an increase in volume and the need for analysis of such agreements, as individuals in industries traditionally unrelated to health care – such as IT vendors –find themselves confronting issues respecting a BAA. The increase in BAA’s has also generated an increase in articles and commentators opining on advisable BAA provisions. Most of these articles focus, as one would expect, on the functional aspects of the BAA. This “meaty” part of the BAA, however, is not the only important part of the agreement. Less frequently have commentators discussed “boilerplate” or “standard” provisions found in most contracts, including BAA’s.

In spite of the seemingly self-explanatory term given to these provisions, they are not always standard and, more importantly, not advisable in all circumstances. The BAA is similar to other contracts in that certain boilerplate provisions sometimes work in the favor of both parties, whereas other provisions may be unduly limiting or even detrimental to both parties, while some provisions favor the party that is the covered entity (“CE”) over the business associate (“BA”), or vice versa. In reviewing BAA’s, I have noticed that certain standard provisions, often tacked on to the end of the BAA, may be detrimental to both parties, and other standard provisions that should have been included were absent. Below is a list of some standard contract provisions and how they might operate in a BAA:

Choice of Law: This provision allows the parties to choose what law governs the contract. Although federal law governs the required content of a BAA, the actual interpretation of the contract, damage awards, and other substantive issues are governed by state law. As such, each party should request to use an applicable state law that will favor its position.

Jurisdiction and Venue: This standard provision requires the parties to litigate any claims under the BAA in a specific state and county. In most cases, as a matter of convenience and economy, each party to an agreement will want jurisdiction and venue to be in its respective home county. CE’s, however, should be mindful that a large HIPAA breach would be likely to reflect negatively on it within the community, even if the breach is legally attributable to actions or inactions of the BA. A CE should take this into consideration, along with its reputation in the community, when deciding to assign venue to its home county.

Force Majeure: Under contemporary contract law, a party is liable for a breach (in most cases) regardless of fault. A Force Majeure provision alleviates the harshness of this rule by eliminating liability for a breach where the action or omission that caused the breach was beyond the reasonable control of the breaching entity. Examples typically include floods, earthquakes, terror attacks and other events beyond the parties’ control. In a typical BAA arrangement, the BA has more obligations than the CE (often because the BAA was originally drafted by the CE). A CE, therefore, should carefully consider whether a Force Majeure provision will advance its interest. BA’s, on the other hand, will often benefit from a Force Majeure provision.

Indemnification: An indemnification provision requires the breaching party to act as an indemnitor to the non-breaching party, covering liability, costs and damages as a result of the breach. This provision often requires negligence on the part of the breaching party and may or may not be reciprocal. Because the CE more likely than not has more to lose than the BA, a reciprocal indemnity provision favors a CE more than a BA.  (A prior posting on this blog provided a list of ten items to contemplate if an indemnification provision is being considered for a BAA.)

Third Party Beneficiaries: A Third Party Beneficiary (“TPB”) is a person or group that claims rights under a contract to which the TPB is not a party. Because HIPAA does not create a private right of action, patients and other injured parties cannot use HIPAA directly to sue for damages. A BAA could, potentially, create a “backdoor” right to enable patients and other third parties to sue the CE and/or BA under a TPB theory. For that reason, both parties to the BAA should agree on and include a standard provision that excludes TPB from the contract.

These are just a few of the standard provisions in contracts, and parties should carefully consider including them in their BAA. Certain facts, updated regulations, state law peculiarities or other circumstances might alter the general rules discussed here.

[Michael Coco handles a range of corporate matters, focusing his practice primarily in the area of health law. As a former ER staff nurse and chemist, Michael has in-depth insight into such topics as FDA approval of medical devices as well as hospital compliance with federal and state laws and regulations, including privacy and security of health information and professional standards.]

The recent release of the HIPAA/HITECH “mega rule” or “omnibus rule” has given bloggers and lawyers like us plenty of topics for analysis and debate, as well as some tools with which to prod covered entities, business associates and subcontractors to put HIPAA/HITECH-compliant Business Associate Agreements (“BAAs”) in place. It’s also a reminder to read BAAs that are already in place, and to make sure the provisions accurately describe how and why protected health information (“PHI”) is to be created, received, maintained, and/or transmitted. 

If you are an entity that participates in the Medicare Shared Savings Program as a Medicare Accountable Care Organization (“ACO”), your ability to access patient data from Medicare depends on your having signed the CMS Data Use Agreement (the “Data Use Agreement”). Just as covered entities, business associates, and subcontractors should read and fully understand their BAAs, Medicare ACOs should make sure they are aware of several Data Use Agreement provisions that are more stringent than provisions typically included in a BAA and that may come as a surprise. Here are ten provisions from the Data Use Agreement worth reviewing, whether you are a Medicare ACO or any other business associate or subcontractor, as these may very well resurface in some form in the “Super BAA” of the future:

 

1.         CMS (the covered entity) retains ownership rights in the patient data furnished to the ACO.

 

2.         The ACO may only use the patient data for the purposes enumerated in the Data Use Agreement.

 

3.         The ACO may not grant access to the patient data except as authorized by CMS.

 

4.         The ACO agrees that, within the ACO and its agents, access to patient data will be limited to the minimum amount of data and minimum number of individuals necessary to achieve the stated purposes.

 

5.         The ACO will only retain the patient data (and any derivative data) for one year or until 30 days after the purpose specified in the Data Use Agreement is completed, whichever is earlier, and the ACO must destroy the data and send written certification of the destruction to CMS within 30 days.

 

6.         The ACO must establish administrative, technical, and physical safeguards that meet or exceed standards established by the Office of Management and Budget and the National Institute of Standards and Technology.

 

7.         The ACO acknowledges that it is prohibited from using unsecured telecommunications, including the Internet, to transmit individually identifiable, bidder identifiable or deducible information derived from the patient files. 

 

8.         The ACO agrees not to disclose any information derived from the patient data, even if the information does not include direct identifiers, if the information can, by itself or in combination with other data, be used to deduce an individual’s identity.

 

9.         The ACO agrees to abide by CMS’s cell size suppression policy (which stipulates that no cell of 10 or less may be displayed).

 

And last, but certainly not least:

 

10.       The ACO agrees to report to CMS any breach of personally identifiable information from the CMS data file(s), loss of these data, or disclosure to an unauthorized person by telephone or email within one hour.

  

While the undertakings of a Medicare ACO and the terminology in the Data Use Agreement for protection of patient data may differ from those of covered entities, business associates and subcontractors and their BAAs under the HIPAA/HITECH regulations, they have many striking similarities and purposes.