Part 4 of the “Preparing for Joint Commission AI Certification” series

Your standard Business Associate Agreement wasn’t written for AI. The RUAIH guidance makes clear that healthcare organizations need to think beyond HIPAA basics when negotiating data relationships with AI vendors-and that data use agreements should explicitly address how patient information flows through AI systems.

Why Standard BAAs Aren’t Enough

A Business Associate Agreement addresses HIPAA compliance: the vendor agrees to protect PHI, report breaches, and follow covered entity instructions. That’s necessary, but it doesn’t address AI-specific questions:

  • Can the vendor use your patient data to train or improve their AI models?
  • Who owns the outputs generated by AI analyzing your data?
  • Can the vendor aggregate your data with other customers’ data for analytics or product development?
  • What happens to your data if you terminate the relationship?

The RUAIH guidance explicitly calls for healthcare organizations to “establish requirements within their data use agreements to limit the permissible uses of exported data” and to “clearly define the permissible uses of exported data in data use agreements.”

This is the difference between a vendor that complies with HIPAA and one that respects your expectations for data stewardship.

Key Clauses to Negotiate

1. Permitted Uses and Prohibitions

The foundation of any AI data use agreement is clear definition of what the vendor can and cannot do with data.

Specify permitted uses:

  • Processing data solely for providing contracted services
  • Generating outputs for your organization’s use
  • Temporary storage as necessary for processing

Explicitly prohibit:

  • Using your data to train, retrain, or improve AI models without express written consent
  • Sharing your data with third parties beyond contracted subprocessors
  • Aggregating your data with other customers’ data for product development
  • Selling or licensing insights derived from your data
  • Any use of data for vendor’s commercial benefit beyond contracted services

Sample language: “Vendor shall use Customer Data solely to provide the Services described in this Agreement. Vendor shall not use Customer Data to train, develop, improve, or enhance any machine learning models, algorithms, or AI systems, whether for Customer’s benefit or otherwise, without Customer’s prior written consent for each specific use.”

2. Model Training and Improvement Rights

This deserves its own section because it’s where negotiations often break down. Many AI vendors want to use customer data to improve their products-it’s how AI systems get better. But you should control whether and how your patient data contributes.

Questions to ask:

  • Does the vendor use customer data for model training? If so, is it aggregated and de-identified?
  • Can you opt out of contributing data to model improvement?
  • If you consent to training data use, what safeguards prevent re-identification?
  • Will you receive any benefit (pricing, features) for contributing training data?

Consider a tiered approach:

  • Prohibition on using identifiable data for training (non-negotiable)
  • Option to contribute de-identified data to model improvement (your choice)
  • Clear de-identification standards if you opt in (Safe Harbor or Expert Determination)

3. Data Minimization

The RUAIH guidance endorses HIPAA’s “minimum necessary” standard applied to AI: “Ensure that only the minimum necessary data is exported and used for the specified purposes.”

Negotiate for:

  • Vendor access limited to data elements required for the specific use case
  • Regular reviews of data access to ensure continued necessity
  • Automatic purging of data no longer needed for service delivery

Ask vendors:

  • What specific data elements does your AI require?
  • How do you ensure you’re not over-collecting?
  • What’s your data retention policy?

4. Prohibition of Re-identification

When de-identified data is used (for analytics, benchmarking, or model training), explicitly prohibit re-identification attempts.

Sample language: “Vendor shall not attempt to re-identify any de-identified data, shall not combine de-identified data with other data sources in a manner that could enable re-identification, and shall contractually require the same prohibition from any subcontractors or downstream recipients.”

This seems obvious, but without explicit prohibition, you’re relying on good faith.

5. Ownership of Outputs

Who owns the AI-generated outputs? This matters more than you might think.

Clinical outputs: Notes generated by AI scribes, risk scores, diagnostic suggestions-these should unambiguously belong to you as part of the medical record.

Aggregate insights: If the vendor provides benchmarking or analytics, who owns those insights? Can you share them? Can the vendor use them in marketing?

Derived data: If the AI generates new data elements (predictions, classifications), clarify ownership.

Sample language: “All outputs generated by the Services using Customer Data shall be owned by Customer and constitute Customer’s Confidential Information. Vendor acquires no rights in such outputs other than as necessary to provide the Services.”

6. Audit Rights

Trust but verify. Reserve the right to audit vendor compliance with data use restrictions.

Negotiate for:

  • Annual audit rights (at your expense, with reasonable notice)
  • Right to audit following any security incident
  • Vendor provision of SOC 2 reports or equivalent third-party attestations
  • Right to request certifications of compliance with specific agreement terms

7. Security Requirements

Beyond standard HIPAA security, consider AI-specific requirements:

  • Encryption of data at rest and in transit (should be baseline)
  • Access controls limiting who within the vendor organization can access your data
  • Logging of all data access with audit trail retention
  • Security assessment requirements for the AI system itself (not just infrastructure)
  • Incident response timelines specific to AI-related anomalies

8. Termination and Data Return/Destruction

What happens to your data when the relationship ends?

Specify:

  • Timeline for data return and/or destruction (typically 30-60 days)
  • Certification of destruction requirement
  • Format for returned data
  • Confirmation that your data has been removed from any training datasets (if applicable)
  • Survival of confidentiality and use restrictions beyond termination

Red Flags in Vendor Contracts

Watch for contract language that should trigger negotiation:

“Vendor may use Customer Data to improve Services” - Too broad. Improve how? Require specificity and consent rights.

“Aggregated and anonymized data may be used…” - What’s the anonymization standard? Who determines if it’s adequate?

“Vendor retains a license to use outputs for…” - Why does the vendor need a license to your outputs?

“Customer grants a perpetual, irrevocable license…” - To what? This language rarely belongs in healthcare data agreements.

Absence of re-identification prohibition - If it’s not prohibited, it’s permitted.

Vague incident notification timelines - “Promptly” isn’t a timeline. Specify hours for breach notification.

The RUHD Framework

The Joint Commission’s Responsible Use of Health Data (RUHD) framework, referenced in the RUAIH guidance, provides additional structure for secondary data use. Key elements include:

  • Oversight structure for data use decisions
  • Patient transparency about secondary uses
  • Algorithm validation requirements
  • Permitted use definitions
  • Data controls and de-identification processes

While primarily focused on health systems’ own secondary use of data, these principles inform what you should expect from vendors as well.

Practical Negotiation Tips

Start early. Data use terms are easier to negotiate before you’re committed to a vendor. Once you’re mid-implementation, leverage disappears.

Involve the right people. Legal drafts the language, but IT should validate technical feasibility and compliance should assess risk.

Know your non-negotiables. Prohibition on training data use without consent should be non-negotiable. Specific audit frequencies might be flexible.

Get specifics in writing. Vendor sales teams make promises; contracts create obligations. If a vendor verbally commits to something, get it in the agreement.

Plan for the relationship lifecycle. Today’s startup vendor might be acquired tomorrow. Ensure your data use restrictions survive corporate changes.

A Note on Existing Contracts

If you have AI vendors already operating under standard BAAs without these provisions, you’re not alone. Consider:

  • Requesting contract amendments for highest-risk AI tools first
  • Adding data use provisions at contract renewal
  • Documenting vendor verbal commitments even if not yet contractual
  • Including enhanced terms in all new vendor agreements going forward

Perfect shouldn’t be the enemy of good. Improving data use governance incrementally is better than waiting for every contract to be renegotiated.

Next in the series: Monitoring AI Performance: A Risk-Based Approach for Resource-Constrained Health Systems

Harness.health helps regional health systems build AI governance programs aligned with Joint Commission RUAIH guidance. Learn more about our platform