Business associate agreement (BAA)

Healthcare organizations need to understand BAA requirements before implementing analytics. Without a signed Business Associate Agreement, you’re operating in violation of HIPAA the moment you start tracking user behavior on patient-facing websites or apps.

What is a BAA

A business associate agreement (BAA) is a contract between a HIPAA-covered organization and its business associates. It obliges both sides of the contract to protect protected health information (PHI) and comply with the guidelines provided by HIPAA.

A business associate is any third party that has access to PHI on behalf of a covered entity. This includes analytics platforms that collect data from patient portals, appointment booking systems, telehealth platforms, or any other digital property where patients’ interactions could be linked to their health information or identity.

BAA requirements

BAAs require that:

  • A company dealing with PHI obtains sufficient assurances from its business associates that they will appropriately safeguard the information
  • The business associate will safeguard the PHI on the company’s behalf according to HIPAA Security Rule and Privacy Rule requirements
  • The business associate implements appropriate administrative, physical, and technical safeguards to protect PHI

Under the HITECH Act (the Health Information Technology for Economic and Clinical Health Act), any HIPAA business associate automatically becomes subject to audits performed by the U.S. Department of Health and Human Services (HHS) and can be held directly accountable for data breaches or improper handling of data – not just the covered entity.

What should be in a BAA

HIPAA requires that every BAA contains certain elements. According to HHS guidelines, the contract must:

  • Describe the business associate’s permitted and required uses of protected health information with specific limitations on use cases
  • Provide that the business associate will not use or further disclose the protected health information other than as permitted or required by the contract or as required by law
  • Require the business associate to use appropriate safeguards (including technical, physical, and administrative safeguards) to prevent the use or disclosure of protected health information other than as provided for by the contract
  • Require the business associate to report to the covered entity any use or disclosure of the information not provided for by the contract
  • Establish the business associate’s obligations in the event of a breach, including notification timelines and responsibilities

Warning signs in BAA negotiations

Vendor won’t sign a BAA: This immediately disqualifies them for any HIPAA-related use case. Some analytics vendors claim their service doesn’t access PHI, but if they’re collecting data from patient-facing digital properties, they almost certainly do.

BAA has carve-outs for “de-identified data”: Be cautious with vendors who want to use or share de-identified versions of your data. HIPAA’s de-identification requirements are strict, and many vendors’ de-identification processes don’t actually meet the standard.

Vendor wants you to warrant that no PHI will be transmitted: This shifts all responsibility to you and may not be realistic. Patient behavior on health-related websites often constitutes PHI even if you’re not explicitly collecting medical records.

BAA lacks specifics on technical safeguards: A BAA should reference specific security measures like encryption at rest and in transit, access controls, audit logging, and incident response procedures. Generic language about “appropriate safeguards” isn’t sufficient.

Questions to ask analytics vendors

Before implementing any analytics solution in a healthcare setting:

  1. Will you sign a Business Associate Agreement?
  2. Have you completed a HIPAA security assessment?
  3. What specific technical safeguards do you implement for PHI?
  4. Where is data stored geographically, and who has access to it?
  5. What is your process for breach notification and incident response?
  6. Do you have HITRUST certification or similar third-party validation?
  7. Can you provide references from other HIPAA-covered entities?

If they can’t answer these questions satisfactorily, they’re not ready to handle PHI.

You may also like: