> ## Documentation Index
> Fetch the complete documentation index at: https://dso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.
# LLMs, zero data retention, and HIPAA
> Zero data retention is a storage control, not a compliance status. Why vendors treat it as a precondition for handling PHI, why it is not the same as HIPAA, and where the PHI actually persists in a dental group.
**Zero data retention (ZDR)** is a configuration in which an AI provider does not persist your prompts and outputs after serving the request. It can reduce retention risk, and vendors frequently require it before they will handle regulated data. ZDR alone does **not establish HIPAA compliance** or replace a business associate agreement. In at least one major provider's current terms, it is not uniformly compatible with the services covered by the provider's BAA.
This page explains the framework. Whether a specific AI deployment may handle your PHI depends on its configuration, your contracts, and applicable state law. Confirm the conclusion with privacy counsel. Vendor terms change frequently, so **verify them against current documentation and your executed agreement**.
## What ZDR actually is
By default, most AI providers retain API inputs and outputs for a period, commonly around 30 days, for abuse monitoring, trust and safety review, and debugging. **ZDR turns that logging off**: the data exists transiently while the request is processed and is not written to durable storage afterward.
The setting describes a vendor's storage behavior for a particular configuration and set of covered services. It says nothing by itself about the rest of the data flow.
### Controls that ZDR does not replace
| Not the same as | Why it's different |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **"They don't train on my data"** | A provider can decline to train on your inputs while still retaining them for 30 days. No-training is now standard on enterprise and API tiers; it says nothing about retention. |
| **Encryption** | Encryption protects data in transit and at rest. ZDR is about whether it is written at rest at all. You want both. |
| **A BAA** | A contract allocating HIPAA obligations. ZDR is a technical setting. **Neither implies the other.** |
Review **data residency**, **subprocessors**, and retention of derived artifacts such as embeddings, caches, and safety classifications separately.
## Why vendors treat it as a precondition
If an AI provider creates, receives, maintains, or transmits PHI on a covered entity's behalf, it may be a **business associate** under 45 C.F.R. § 160.103 and require a BAA. The exact relationship and contracting chain depend on who engages the provider and for what function.1
General-purpose abuse-monitoring logs may place PHI in additional systems and expose it to a broader review process. ZDR can reduce the amount of PHI at rest, the number of systems in scope, and the consequences of a security incident.
Some vendors make ZDR **a condition of BAA coverage or permission to send regulated data** for particular services. Treat that as a vendor- and service-specific contract term.
## ZDR and BAA coverage do not always align
Review coverage at the service and feature level before choosing an architecture.
**BAA coverage is scoped per service, not per vendor.** Providers publish which of their products and endpoints the BAA covers, and the exclusions are frequently substantial. Anthropic, for example, publicly documents that its BAA covers the Messages API and specified Claude Enterprise features, while **explicitly excluding** its Batch API, Files API, Skills API, Code Execution, Computer Use, and Web Fetch.2
**And ZDR can point in the opposite direction.** In the same documentation, Anthropic states that certain covered models **require 30-day data retention and are not available with ZDR enabled**, while a different covered service is **only** covered under the BAA **when ZDR is enabled**.2
**A vendor may require retention for one BAA-covered service and require ZDR for another.**
Treat ZDR and BAA coverage as separate settings that vary by service. Enabling ZDR does not establish that a particular endpoint, feature, model, or subprocessor falls within the executed BAA.
We cite Anthropic because it publishes unusually explicit documentation. Other major providers offering BAAs, including OpenAI and Azure OpenAI, Google Vertex AI, and AWS Bedrock, publish service-specific coverage matrices with their own exclusions. **Read your vendor's current matrix and executed agreement.**
## Why ZDR is not HIPAA compliance
Even with ZDR enabled, a signed BAA, and a covered service, the deploying organization retains its own HIPAA obligations.
### 1. Transmission is a disclosure
Sending PHI to a third party is a disclosure under the Privacy Rule regardless of what happens to it afterward. The disclosure must be permitted for treatment, payment, health care operations, or under an authorization, and it must satisfy the **minimum necessary** standard when that standard applies.
ZDR does not make an impermissible disclosure permissible; it addresses retention after the disclosure.
### 2. Minimum necessary still applies to the prompt
ZDR governs retention after a request. The minimum-necessary standard, when applicable, governs what information is sent. Prompt design should therefore limit PHI to the fields needed for the permitted function.
### 3. The Security Rule applies to your systems
Access controls, audit logging, workforce training, and the required **security risk analysis** under 45 C.F.R. § 164.308(a)(1)(ii)(A) all cover your AI integration as an asset that handles ePHI. A vendor's retention setting does not discharge any of them.
OCR proposed a major update to the HIPAA Security Rule in **January 2025**, including removal of the required/addressable distinction and tighter risk-management and encryption expectations. **Confirm the proposal's current status** before relying on either framework.3
### 4. Business associates are directly liable
Since the HITECH Act and the 2013 Omnibus Rule, business associates have independent HIPAA obligations and are subject to enforcement in their own right. **In a DSO-PC group, that means the dental support organization (DSO)**, and the AI provider as the DSO's subcontractor.
### 5. Patient rights still apply
If an AI-drafted note becomes part of the designated record set, it is subject to patient access and amendment rights. The record lives in your PMS; the vendor's retention setting is irrelevant to it.
### 6. Breach notification still attaches
An impermissible disclosure of unsecured PHI is **presumed to be a breach** unless you document a low probability of compromise. Disclosing PHI to a vendor with no BAA is potentially reportable whether or not the vendor stored it.
### 7. Stricter regimes sit on top
State health privacy laws can be stricter than HIPAA, and some states now regulate AI in health care directly. Washington, for example, provides that AI may not be the sole means used to deny, delay, or modify health care services and requires human review for medical-necessity denials.4 HHS has separately addressed nondiscrimination in patient-care decision support tools.5
## Where PHI may remain in your systems
ZDR at the model provider does not cover copies stored by the application, gateway, monitoring tools, or support systems. Inventory the full path rather than reviewing only the model endpoint.
| Your system | Holds PHI? |
| -------------------------------------------------------------- | ------------------------------------------------------------- |
| **Application logs**, Datadog, Sentry, CloudWatch, and similar | **Yes**, if prompts or outputs are logged |
| **Error monitoring and stack traces** | **Yes**, frequently including request payloads |
| **Conversation or chat history** in your database | Yes |
| **Vector stores and embeddings** | **Yes**, embeddings derived from PHI should be treated as PHI |
| **Evaluation and test datasets** | **Yes**, a "golden set" of real prompts is a PHI store |
| **Prompt caching** | **Yes, by definition**, caching is retention |
| **Model gateway or proxy logs** | Yes |
| **Support tickets with screenshots** | Yes, and frequently overlooked |
| **Analytics on prompt content** | Yes |
**Prompt caching deserves specific attention.** It is a retention mechanism whose entire purpose is persisting request content, it is frequently enabled by default for cost reasons, and it can operate at the vendor, at a gateway, or in your own application. Confirm where cached content lives, for how long, and whether it is inside your BAA's scope.
Every one of these belongs in your BAA inventory and your security risk analysis. See [Build a minimum viable HIPAA program](/guides/compliance/build-a-hipaa-program).
## The DSO-PC chain
The structure adds two links most guidance doesn't contemplate.
```mermaid theme={null}
graph LR
PC["PC
covered entity
(one per state)"] -->|BAA| DSO["DSO
business associate"]
DSO -->|subcontractor BAA| LLM["AI provider
business associate,
directly liable"]
LLM -->|its own agreements| CLOUD["Cloud infrastructure
and subprocessors"]
```
Practical consequences:
* **One BAA per PC.** Each professional entity is a separate covered entity. A ten-PC group needs ten DSO-PC BAAs, and those BAAs need to actually contemplate the AI use.
* **The DSO needs a subcontractor BAA with the AI provider**, and must ensure it flows the same restrictions down.
* **Keep records segregated by PC.** A shared AI tool spanning several PCs should prevent one practice's context from appearing in another's workspace, consistent with the applicable record-ownership and access rules.
* **The DSO has direct regulatory duties** in its role as a business associate; its liability does not arise solely from the contract.
The concrete case this wiki keeps flagging: **835 remittance files are PHI.** Running them through a model for denial root-cause classification puts PHI in a prompt. Teams build that as a finance project and miss the BAA, the encryption, and the risk analysis entirely. See [The 835](/concepts/payments/understanding-835s).
## The CPOD overlay, the part unique to this structure
Privacy is not the only exposure. **A DSO deploying AI that influences clinical decisions may be exercising a function the corporate practice of dentistry (CPOD) doctrine reserves to the PC.**
Recall what the newest corporate-practice statutes actually enumerate. **California's SB 351** bars management entities from participating in **billing, coding, equipment selection, and clinical staff oversight**, and bars private equity groups and hedge funds from **determining what diagnostic tests are appropriate** or **determining the need for referrals**. **Oregon's SB 951** reaches management-entity control over **scheduling, clinician compensation, coding, billing, and payer contract terms**.6
Now map AI onto that list. Dentistry's AI wave is arriving through exactly these doors: radiograph-analysis tools that flag caries, bone loss, and calculus; PMS-integrated coding assistants; scheduling optimizers.
| DSO-deployed AI tool | Risk |
| ------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **Auto-assigns procedure codes** with no meaningful dentist override | The DSO is determining coding, named in both statutes |
| **Turns radiograph findings into a treatment plan** the dentist is expected to accept | The DSO's tool is determining diagnosis and treatment need |
| **Drives scheduling density or appointment length** | Named in SB 951 |
| **Screens or ranks clinical staff** | Clinical staff oversight |
| Radiograph analysis that flags findings a dentist confirms or rejects | Defensible, this is support |
| Surfaces coding *suggestions* a dentist reviews and can reject | Defensible, this is support |
| Drafts documentation the dentist edits and signs | Defensible, the dentist authors |
**The test is the same one this wiki applies everywhere: who decides, and who merely implements?**
AI that surfaces options for a dentist who genuinely decides is **support**. AI that decides and informs the dentist is **control**, regardless of what the management services agreement (MSA) says, and regardless of whether a human nominally clicks approve on a queue of a thousand items.
If you build clinical or coding AI in the DSO, document that the **PC approved the tool**, that dentists can reject its output, and that rejection actually happens at a rate consistent with genuine review. See [What a DSO can and can't do](/concepts/model/what-dsos-can-and-cant-do) and [Run a CPOD self-audit](/guides/compliance/run-a-cpod-self-audit).
There is also a records question: if AI output becomes part of the clinical record, **the PC owns it**, not the DSO that built the tool.
## De-identification: the other route
If data is properly de-identified under 45 C.F.R. § 164.514 through **Safe Harbor** or **Expert Determination**, it is no longer PHI for HIPAA purposes. Safe Harbor requires removal of the 18 specified identifiers and no actual knowledge that the remaining information could identify a person.7
For some analytics uses, proper de-identification can remove the data from HIPAA's definition of PHI.
**Free-text clinical narratives are difficult to de-identify reliably.** Safe Harbor's identifier list is straightforward for structured fields, but prose can contain identifying context such as an unusual presentation, a referring dentist's name, an embedded date, or an employer description. Automated de-identification of notes has a meaningful error rate. Imaging raises separate questions because Safe Harbor includes full-face photographs and comparable images. Get expert advice before treating a radiograph or photo set as de-identified.
If you rely on de-identification for anything sensitive, use Expert Determination and document it. Do not assume a regex pass over notes produces de-identified data.
## Unapproved consumer AI use
Day-to-day exposure may come from staff using consumer tools outside the approved workflow. For example, a front-desk coordinator might paste a patient's chart into a consumer chatbot to draft an appeal narrative for a downgraded crown.
Sending PHI to a vendor without the required BAA is an impermissible disclosure. Technical controls alone will not prevent it. Use **an acceptable-use policy, workforce training that names the behavior, and an approved tool that meets the team's practical needs.**
Training should state the rule plainly: *never paste patient information into an AI tool that isn't on the approved list.*
## Deployment controls
De-identified data, structured fields only, or a locally hosted model may serve the use case. This is the cheapest control available.
And confirm **which services and endpoints it covers**. Exclusions are frequently substantial.
Not what you assume. It may require ZDR on, or off, depending on the service.
You → DSO → provider → its cloud and subprocessors. Every link handling PHI needs an agreement.
Application logs, error monitoring, chat history, vector stores, eval datasets, prompt caches, gateway logs, support tickets.
Send the fields the task needs, not the record.
As an asset that handles ePHI.
Who used it, on which patient, when.
Document PC approval and genuine dentist override.
## The one-sentence version
**ZDR is a useful control that reduces how much PHI sits at a vendor. HIPAA is a set of obligations on you that ZDR does not touch, and the two are configured independently, sometimes in opposite directions.**
## Sources
1. 45 C.F.R. § 160.103 (definitions of business associate and covered entity); business associate contract requirements at 45 C.F.R. § 164.504(e). [eCFR](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103).
2. Anthropic, [Is Anthropic willing to sign a BAA?](https://privacy.claude.com/en/articles/8114513-is-anthropic-willing-to-sign-a-baa). Cited because it publicly documents the per-service coverage matrix and the ZDR interaction; other major providers publish their own. This is not an endorsement. Read the vendor's current terms.
3. HHS OCR proposed HIPAA Security Rule update, January 2025. **Confirm current status.** See HIPAA Journal, [HIPAA Updates and HIPAA Changes](https://www.hipaajournal.com/hipaa-updates-hipaa-changes/).
4. State AI-in-healthcare laws, including Washington's provision that AI not be the sole means of denying, delaying, or modifying care. See Live Compliance, [AI in Healthcare: The Regulatory Landscape](https://livecompliance.com/learn/ai-healthcare-regulations/). **Verify current text and effective date against the state's own statute.**
5. HHS OCR, "Ensuring Nondiscrimination Through the Use of Artificial Intelligence and Other Emerging Technologies," addressing patient care decision support tools. See Reed Smith, [HHS Recent Guidance on AI Use in Health Care](https://www.reedsmith.com/our-insights/blogs/health-industry-washington-watch/102k29k/hhs-recent-guidance-on-ai-use-in-health-care/).
6. Cal. S.B. 351 (2025); Or. S.B. 951 (2025). Both are written for health care management entities generally; their enumerated lists are the clearest statutory statement of what a management company must not control. See the [legislation tracker](/reference/legal/dental-legislation-tracker) for citations, effective dates, and the dental-specific analogues.
7. 45 C.F.R. § 164.514(a)–(b). HHS, [Guidance Regarding Methods for De-identification of PHI](https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html).