When a radiology department evaluates an AI vendor, someone in procurement or IT governance will ask about HIPAA compliance. The vendor will say yes, we are HIPAA-aligned, and produce some documentation. What those words mean operationally, and what you should actually verify before signing a BAA, is worth unpacking in detail.
This is not a legal guide, and nothing here constitutes legal advice. But having worked through the data controls evaluation with multiple imaging departments, we have a reasonably clear picture of where the meaningful questions are and where the surface-level assurances often fall short.
The BAA Is the Starting Point, Not the End Point
A Business Associate Agreement is required under the HIPAA Privacy Rule (45 CFR 164.308(b)) any time a covered entity shares PHI with a vendor. If your radiology AI tool touches identifiable patient imaging data, the vendor is a business associate, and you need a BAA. This is not controversial.
The BAA establishes the legal relationship and the vendor's obligations. What it does not do is tell you how those obligations are actually implemented. A vendor can sign a BAA that says they will protect PHI and delete it upon contract termination while having data practices that are sloppy in ways the BAA text does not surface. The BAA is a compliance artifact. The technical controls are what actually protect the data.
Ask specifically: where does PHI sit during processing, what is the retention policy for study data and derived outputs, and does the vendor's model training pipeline ever use identified patient data? That last question matters more than it sounds. Some early medical AI vendors used production patient data to improve models in ways that were not clearly disclosed. The acceptable answer today is that model training uses only appropriately de-identified or consented datasets, and that production patient data is used for inference only within the terms of the BAA.
De-Identification: Expert Determination vs. Safe Harbor
HIPAA defines two methods for de-identifying PHI under 45 CFR 164.514(b). The Safe Harbor method requires removing 18 specific identifiers from the data, including patient name, geographic data smaller than state, all dates except year, phone and fax numbers, medical record numbers, and device identifiers. Expert Determination requires a qualified statistician to certify that residual re-identification risk is very small.
For radiology AI, the relevant PHI lives in two places: the DICOM header and the image pixel data. The DICOM header contains obvious identifiers like patient name, MRN, date of birth, and study date. Most tools that claim HIPAA alignment strip these tags before any data leaves the local environment or before processing. Verify this is happening at the network boundary, not downstream after transmission.
Pixel data is more subtle. Retinal photography and certain facial reconstruction scenarios have well-documented risks of patient identification from image data alone. For typical CT, MRI, and plain film, this risk is lower, but it is not zero. Expert determination is the more defensible approach for vendors handling imaging data at scale, because the Safe Harbor 18-identifier removal does not speak to pixel-level identifiability. Ask the vendor what method they use and whether they have documentation from a qualified statistician.
Audit Logs: What They Must Capture and What Often Gets Missed
The HIPAA Security Rule requires covered entities and their business associates to implement audit controls that record and examine activity in systems containing or using ePHI (45 CFR 164.312(b)). For a radiology AI tool, meaningful audit logging means recording who accessed what study data, when, what action was taken (pre-read processing, draft generation, worklist update), and whether there were any transmission events to external systems.
What often gets missed in vendor implementations: the audit trail for derived outputs. If the AI generates a structured draft report and that draft is transmitted to your PACS or dictation system via HL7, the audit log should record not just the API call but the content of the transmission. If there is a discrepancy later between what was in the AI draft and what appeared in the signed report, you need to be able to trace the chain. Logs that capture access events but not content transmission events leave a gap.
The other gap we see regularly: audit log integrity. It is not enough to collect logs. They need to be stored in a tamper-evident format, with access controls that prevent the system being audited from modifying its own audit trail. For cloud-hosted AI tools, this usually means logs are written to a separate, isolated storage layer with append-only permissions. Ask for specifics, not just a checkbox that audit logging is enabled.
Encryption and Transmission Security
The minimum bar for transmission security under the HIPAA Security Rule is that ePHI in transit must be encrypted. TLS 1.2 or higher is the current floor. Any radiology AI tool transmitting DICOM data or HL7 messages over a network connection that does not implement current TLS standards is a red flag regardless of what their BAA says.
At rest, AES-256 is the de facto standard for encrypted storage of ePHI in cloud environments. Ask specifically about key management. Encryption at rest is only meaningful if the key management is separate from the data. If the vendor manages encryption keys in the same environment as the encrypted data, the encryption provides limited protection against a compromised environment. AWS KMS, Azure Key Vault, and Google Cloud KMS are all acceptable key management approaches that provide the separation needed.
For on-premise or hybrid deployments, which are common in hospital radiology environments, the data transmission model is different. If the AI processing happens locally on a virtual machine within the hospital's own network perimeter, the external transmission surface is smaller. But the same encryption standards apply to any data that leaves the hospital network boundary, including log exports, anonymized feedback data, and model update payloads.
Minimum Necessary and Data Retention
The HIPAA minimum necessary standard (45 CFR 164.502(b)) requires that access to PHI be limited to what is needed for the stated purpose. For a radiology AI pre-read tool, the stated purpose is generating a triage priority and draft report for a given study. The data necessary for that purpose is the imaging study and the relevant prior studies for comparison. Patient contact information, billing data, and other PHI that might be in the EHR is not necessary for the pre-read function and should not be accessible to the AI tool at all.
Data retention is where many vendors have vague policies. The AI tool needs study data for the duration of processing. After the pre-read output is generated, the vendor's retention of the underlying DICOM data should be minimal and time-bounded. Ask for a specific retention schedule: how long is study data retained in the vendor's environment after processing, and what is the deletion process? Indefinite retention of patient imaging data for vague "quality improvement" purposes is not acceptable without explicit consent provisions.
We are not saying every vendor with a retention period over 30 days is non-compliant. But retention that is open-ended or tied to the vendor's business interests rather than the covered entity's patient care purpose warrants a detailed conversation before BAA signature.
What to Ask Before You Sign
The five questions that separate a substantive HIPAA controls evaluation from a checkbox exercise: Where exactly does PHI sit during processing, and what network controls govern that environment? What de-identification method is used, and is there documentation from a qualified statistician? How are audit logs collected, stored, and what events are recorded beyond access? What is the key management architecture for encryption at rest? And what is the specific data retention schedule for study data after pre-read processing completes?
Vendors who have thought carefully about these questions will answer them quickly and specifically. Vendors who have not will give you generic compliance language that sounds good but does not answer what you asked. The quality of the answer is itself informative about how much operational rigor exists behind the BAA.