We have signed BAAs. We have been on the receiving end of BAA requests. We have seen what imaging center administrators ask for and what they miss. This post comes from that dual perspective — we are an AI vendor that processes protected health information, and we have thought carefully about what a good BAA actually needs to say.
This is not legal advice. It is a practitioner's account of what to look for, what language tends to be weak, and what questions to ask before you sign. If your imaging center has in-house counsel or a healthcare compliance officer, this list is a starting point for that conversation, not a substitute for it.
What a BAA Must Cover Under 45 CFR 164.504(e)
A Business Associate Agreement is required when a covered entity (your imaging center) discloses PHI to a business associate that performs a function or service on its behalf. Under 45 CFR 164.504(e), the BAA must: establish the permitted and required uses and disclosures of PHI by the business associate; require the business associate to not use or disclose PHI other than as permitted; require the business associate to use appropriate safeguards; require the business associate to report breaches; and require the business associate to return or destroy PHI at contract termination.
Those are the statutory minimums. In practice, AI vendors in radiology touch PHI in ways that generic BAA templates handle poorly — because those templates were written for billing vendors, not for systems that ingest DICOM studies.
Scope of PHI: What the Vendor Actually Touches
The first thing to nail down is exactly what PHI the vendor processes. For an AI pre-reading tool, this typically includes: DICOM metadata (patient name, date of birth, study date, accession number, referring physician — all PHI under the HIPAA definition), pixel data from the imaging study itself, any structured report or annotation the system generates, and potentially HL7 FHIR messages if the system integrates with your RIS.
Ask the vendor to enumerate specifically what PHI elements their system receives, stores, and transmits. A BAA that says "PHI as provided by covered entity" is acceptable, but you want the vendor to confirm in writing what their system actually ingests — because any element they receive but did not disclose is a potential gap in your audit trail.
One question that surfaces repeatedly: does the vendor use de-identified DICOM images for model training or improvement? Under 45 CFR 164.514, de-identification following the Safe Harbor or Expert Determination method removes HIPAA obligations for that data. But the operative word is "de-identified" — not "anonymized" in a vendor's proprietary sense. Ask for the specific method used and whether it has been reviewed by legal counsel. If the vendor uses DICOM pixel data for any purpose beyond processing your specific studies, that use should be explicitly described and scoped in the BAA.
Subcontractor Chains and Cloud Infrastructure
This is where most BAA reviews get sloppy. The vendor's own BAA says nothing about the cloud infrastructure they run on. Under the HIPAA Omnibus Rule (2013), business associates are directly liable, and their subcontractors who handle PHI are also required to sign BAAs. If your AI vendor runs on AWS, Google Cloud, or Azure, those providers should have BAAs with the vendor, and you should ask for confirmation that such agreements exist.
What you are looking for is a chain of BAAs: covered entity → AI vendor → infrastructure subcontractors. You do not need to read the vendor's AWS BAA, but you should see written confirmation that one exists. A vendor who cannot answer this question confidently is a vendor whose compliance posture you should examine further.
Also ask whether the vendor uses any third-party ML platforms, annotation tools, or model monitoring services that might receive PHI as part of their pipeline. These are subcontractors too, and the same chain-of-BAAs requirement applies.
Breach Notification: Timelines and Specifics
Under 45 CFR 164.410, a business associate must notify the covered entity of a breach "without unreasonable delay and in no case later than 60 days following discovery." That is the statutory ceiling — not a target. In your BAA, you can contractually require faster notification. Many organizations add a 15- or 30-day contractual requirement. That is reasonable.
What matters more than the timeline is the substance of the notification. The BAA should require the vendor to notify you with: the date of the breach (or estimated date range), the nature of the breach (what happened), the PHI involved (which records, which elements), the steps the vendor is taking to mitigate harm, and the contact person at the vendor responsible for the incident response. A BAA that says only "vendor will notify covered entity of breaches" does not give you what you need to meet your own 60-day notification window to affected individuals.
Data Retention and Deletion
When the contract ends, what happens to your PHI? The BAA must address this. Options are: return all PHI to the covered entity, destroy all PHI, or retain it with specified controls if return/destruction is infeasible. "Infeasible" is not a blank check — it should be defined and limited.
For AI vendors, there is often PHI embedded in system logs, caches, model inference artifacts, and backup systems. A deletion requirement that only covers the primary data store may leave PHI in secondary locations. Ask whether the vendor has a documented data destruction process that covers backup systems and logs, and whether that process has been tested.
Also clarify the retention period during the contract. If your contract allows the vendor to retain study data for "quality assurance" purposes after processing, the BAA should specify exactly how long, under what access controls, and whether that data is used for any purpose other than your account's QA. We are not saying such retention is inherently problematic — it is sometimes operationally necessary — but the scope should be explicit, not assumed.
The Minimum Necessary Standard
Under 45 CFR 164.502(b), covered entities and business associates should limit PHI use to the minimum necessary. For an AI pre-reading tool, this means the vendor should be able to articulate what PHI elements are actually needed for the system to function. Accession number and modality type? Almost certainly necessary. Patient name rendered in the ML inference pipeline? Probably not necessary — most inference can run on de-identified or pseudonymized DICOM with only accession number retained for report routing.
This is not a compliance gotcha — it is a data minimization question that good vendors should have already thought through. If a vendor cannot explain why they need each PHI element they process, that is a signal worth noting.
Audit Logging and Access Controls
The BAA should commit the vendor to maintaining audit logs of PHI access within their systems. What you want to know: who within the vendor organization can access your PHI, under what circumstances, and with what logging in place. For a small AI vendor, "our CTO can access prod data for debugging" is a real scenario — and it should be in the BAA or the accompanying security exhibit.
Ask for a security exhibit or addendum that describes: access control model (role-based, with separation of PHI-touching roles), encryption at rest and in transit (AES-256 at rest, TLS 1.2+ in transit is baseline), audit log retention period, and access review cadence. This does not need to be in the BAA itself, but it should be a referenced and binding attachment.
We share our security practices in our security page and are willing to walk prospective customers through our access control model in detail. That transparency is something you should expect from any vendor handling your patients' data.