Last week one of my Compliance Helper clients that is a health insurance company asked me the following question (slightly modified to protect their identity):
For the past two years, we have tried to get business associate (BA) Agreements from some of our BAs. They will not sign because they say that they have already addressed security and privacy within their contract to do work for us. If we are unable to obtain the signed BA agreement but document that we tried and they declined, would we be considered “not in compliance”?
Humor me. Pretend “badges” is synonymous with “BA Agreements”…“I don’t have to show you any stinkin’ badges!” (Image from the “Treasure of the Sierra Madre”)
This is a common problem faced by many CEs, and now the entities contracted to BAs. Here is some information I recommend organizations in similar situations take to discuss with their legal counsel. You can then pass along to your BAs that refuse to sign a BA agreement, as is appropriate to your situation:
1) A contract to do business *is not* the same as a BA Agreement (also called a BA Contract), as defined under HIPAA. The purpose for each type of contract is completely different from the other.
2) HIPAA explicitly requires CEs to get BA Agreements, that include all the required components, from each of their BAs. You can refer them to HIPAA section § 164.504 Uses and disclosures: Organizational requirements. Part (e) in “(1) Standard: Business associate contracts” and “(2) Implementation specifications: Business associate contracts.” See details of the BA Agreement components within http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/adminsimpregtext.pdf
3) The Department of Health and Human Services (HHS) has also issued multiple statements indicating the need for BA Agreements from each BA. One of their recent statements to this effect was within the Final Omnibus Rule, released in January of this year. One passage that explicitly states this is:
“Concerning commenters’ questions about the continued need for business associate agreements given the new direct liability on business associates for compliance, we note that section 13404 of the HITECH Act expressly refers and ties business associate liability to making uses and disclosures in accordance with the uses and disclosures laid out in such agreements, rather than liability for compliance with the Privacy Rule generally. Further, section 13408 of the HITECH Act requires certain data transmission and personal health record vendors to have in place business associate agreements with the covered entities they serve. We also continue to believe that, despite the business associate’s direct liability for certain provisions of the HIPAA Rules, the business associate agreement is necessary to clarify and limit, as appropriate, the permissible uses and disclosures by the business associate, given the relationship between the parties and the activities or services being performed by the business associate. The business associate agreement is also necessary to ensure that the business associate is contractually required to perform certain activities for which direct liability does not attach (such as amending protected health information in accordance with § 164.526). In addition, the agreement represents an opportunity for the parties to clarify their respective responsibilities under the HIPAA Rules, such as by establishing how the business associate should handle a request for access to protected health information that it directly receives from an individual.”
4) The HHS also requires CEs to report their BAs that refuse to comply with such HIPAA requirements. As stated within HIPAA (with key points highlighted):
(ii) A covered entity is not in compliance with the standards in §164.502(e) and paragraph (e) of this section, if the covered entity knew of a pattern of activity or practice of the business associate that constituted a material breach or violation of the business associate’s obligation under the contract or other arrangement, unless the covered entity took reasonable steps to cure the breach or end the violation, as applicable, and, if such steps were unsuccessful:
(A) Terminated the contract or arrangement, if feasible; or
(B) If termination is not feasible, reported the problem to the Secretary.
If a BA refuses to sign a BA Agreement, you can let them know that you must either terminate their contract (most will not want to do this if they value your money) or report them to the HHS. Most BAs will not want to then become scrutinized, quite possibly by an audit, by the HHS.
I recommend you also keep documentation in a central location, such as within BA Tracker, that shows each of your messages you send to the BAs (including date and time), each of your calls (with date and time), and any other communications you’ve had with them. Such documentation demonstrates due diligence on your behalf. If all else fails, then you may need to report them.
Bottom line for organizations of all sizes…
Generally an organization that provides services to covered entities (CEs) that involve storing, accessing or otherwise handling protected health information (PHI) needs to sign a BA Agreement.
This post was written as part of the IBM for Midsize Business (http://Goo.gl/t3fgW ) program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Tags: audit, awareness, BA, BA Agreement, BA contract, breach, business associate, compliance, customer service, data protection, e-mail, electronic mail, email, employees, employment, exception management, facebook, FINRA, HIPAA, hiring, HITECH, HR, human resources, IBM, Information Security, information technology, infosec, insider threat, insider trading, IT security, job applicants, messaging, midmarket, monitoring, non-compliance, personal information, personally identifiable information, personnel, PHI, PII, policies, policy exception, policy management, privacy, privacy breach, privacy laws, privacy professor, privacyprof, Rebecca Herold, Red Flags, risk, risk assessment, risk management, security, sensitive personal information, social media, social network, SPI, surveillance, systems security, training, twitter, walk through