HIPAA Requirements for AI Dental Vendors: What to Ask on the Sales Call

There is no such thing as HIPAA certification. No federal body inspects software and stamps it approved. So when a rep tells you their product is “HIPAA compliant AI dental software,” they are describing their own opinion of their own architecture. That opinion may be correct. It is not evidence.

What HIPAA actually does is impose a specific, enumerated set of obligations on you (the covered entity) and on anyone who touches PHI on your behalf (the business associate). Those obligations are written down. You can check them on a 30-minute sales call if you know what to ask.

Here is what to ask, and why each question matters.

The BAA is mandatory, and it has required contents

If a vendor handles, stores, transmits, or even transiently processes your patients’ data, you need a signed Business Associate Agreement before a single record moves. Not after pilot. Not “we’ll get it over during onboarding.”

A BAA is not a formality — 45 CFR 164.504(e) lists what it has to contain. Read for these five things specifically:

1. Permitted uses. It should say what the vendor may do with PHI. If it says “to provide the Services and for Business Associate’s own product development,” you just consented to something much larger than a scribe.
2. Subcontractor flow-down. The vendor must be required to bind its own subcontractors to the same terms.
3. Breach reporting timeline. The regulation says “without unreasonable delay” and no later than 60 days. Sixty days is uselessly slow for you (more on that below). Negotiate it down.
4. Return or destruction at termination. Required by 164.504(e)(2)(ii)(J). Ask what “destruction” means for backups.
5. Your right to audit or receive documentation. Check that this clause is actually present — it is an easy one to leave out.

Get the BAA as a PDF before the demo ends. A vendor who cannot produce one in under an hour has not thought about this. That includes us: ask for ours through our HIPAA compliance page.

The AI model provider is a subcontractor

This is the question that separates vendors who have mapped their own supply chain from vendors who have not.

Many dental AI products are built on someone else’s model API rather than on a model the vendor trained itself. Where that is the case, the 2013 Omnibus Rule makes that model provider a subcontractor: directly liable under HIPAA, and required to be under a written agreement with your vendor (164.308(b)(2), 164.502(e)(1)(ii)).

So ask: who is your model provider, and do you have a BAA with them? Then ask them to say it out loud rather than pointing at a compliance page. Some model providers will sign a BAA for their enterprise API tiers; consumer-grade endpoints often are not covered. If your vendor is routing dictated PHI through an endpoint with no BAA behind it, the chain is broken at the last link and nothing upstream fixes it.

Ask the same about hosting, transcription, telephony, and storage. Every one of them is a subcontractor.

Encryption: “addressable” on paper, mandatory in practice

Under the Security Rule, encryption is technically an addressable implementation specification (164.312(a)(2)(iv) and (e)(2)(ii)), not a required one. Addressable does not mean optional — it means you must implement it or document in writing why an equivalent alternative is reasonable. Writing that documentation for a system holding clinical PHI is a very hard argument to make.

Two things to confirm:

• In transit: TLS 1.2 or better everywhere, including the vendor’s connection to the PMS and to the model provider.
• At rest: ask whether encryption is at the disk level or the field level. Full-disk encryption protects against someone stealing the server. Field-level encryption protects the individual name, DOB, and note body inside the row. They are not the same control, and vendors use the word “encrypted” for both.

There is also a practical reason to care: the Breach Notification Rule applies to unsecured PHI. PHI encrypted to NIST-specified standards falls outside that definition. Encryption is the difference between an incident and a reportable breach.

Minimum necessary — and why integration method is a compliance question

164.502(b) says use and disclose the minimum PHI necessary for the purpose. This sounds abstract until you look at how a vendor connects to your practice management system.

A vendor with a scoped API connection pulls the records it needs. A vendor with direct database credentials has your entire patient base, forever, with no per-record boundary and usually no way for you to revoke access without breaking something.

Open Dental publishes a third-party vendor list with explicit trust tiers. As listed at the time of writing: 87 Authorized, 11 Authorized in Transition, 22 Dangerous/Unknown, 11 Not Currently Active, plus 14 native integrations. Dangerous/Unknown means direct database access or unwhitelisted plugins. The counts move, so look at the list yourself rather than trusting a number on any page, including this one. Listing is free — vendors request it through vendor.relations@opendental.com — so absence from the Authorized tier is a choice, not a cost problem.

Open Dental is not the only one doing this. Henry Schein One publishes a public vendor list for its API Exchange as well, and requires SOC 2 Type II and OAuth 2.0 of the vendors on it. OAuth matters more than it sounds — it means scoped, revocable tokens instead of a shared password sitting in a config file.

Ask which list the vendor appears on. Then go look yourself.

Audit trails are required, not a premium feature

164.312(b) — audit controls — is a Security Rule standard in its own right, with no implementation specifications beneath it. There is no addressable-versus-required judgement call to make: you implement it. Ask three questions:

• Can you produce a per-user access log showing which staff member viewed which patient record and when?
• Are the vendor’s own employees logged when they access your tenant for support?
• How long are logs retained, and can you export them?

That second one is the tell. Support engineers looking at production data is normal and often necessary. Support engineers looking at production data with no log is not.

Breach notification: the 60-day clock is yours

If a breach happens at the vendor, the vendor notifies you. You notify your patients, within 60 days of discovery.

The catch is what counts as discovery. Under 164.404(a)(2), a business associate’s knowledge can be imputed to you when that business associate is acting as your agent under the federal common law of agency — and whether it is an agent turns on how much control the contract gives you over its work, not on what the contract calls it. Where the vendor is a genuine independent contractor, your clock starts when it notifies you.

Either way, a BAA that hands the vendor the full 60 days is a bad trade. At best your own clock starts on day 60. At worst it started on day one and nobody told you. Push for 5–10 business days in the contract.

Also ask, in writing, who pays for notification letters, credit monitoring, and any state AG filings. If the BAA is silent on cost, assume it lands on you.

Retention and deletion

Ask for numbers, not adjectives:

• How long is each data type retained? Notes, audio, transcripts, images, logs — they usually differ.
• When I terminate, what is the export format and how long do I have to pull it?
• How long until backups age out? Ask for the figure in days. “Indefinitely” is not an answer.

Specificity is the signal. One example of what a specific answer sounds like, from our own stack: in the dictation path, audio is held in memory only and never written to disk, S3, or a database. Only the transcript text persists, for 24 hours, so an interrupted recording can be resumed or a finished dictation continued within that window.

The scoping matters as much as the claim. Separate recording features — opt-in and consent-gated — do upload audio to S3. So a blanket, product-wide “we never store audio” deserves a follow-up: which feature, exactly? Hold every vendor to that resolution, ours included; the same applies to our clinical notes product.

One non-HIPAA note while you are here: several states require all-party consent to record a conversation. That is state wiretap law, not HIPAA, and it applies to any recording feature regardless of what your BAA says.

Does my patient data train the model?

This is a contract question, not a marketing question.

HIPAA permits a business associate to use PHI for its own “proper management and administration” (164.504(e)(2)(i)(A)). Training a general-purpose model is a stretch under that clause, and no regulator has blessed it. So vendors commonly rely on de-identification instead.

Which means the real question is not “do you train on my data?” It is:

• Is the de-identification Safe Harbor (all 18 identifiers under 164.514(b)(2)) or expert determination? If expert determination, who signed it and when?
• Does de-identification apply to free-text note bodies? Safe Harbor on narrative clinical text is genuinely hard — patient names, employers, and relatives leak into the prose.
• Does the model provider retain prompts, and for how long? Ask whether the vendor has a zero-retention arrangement in place and can show it.
• Is there human review of your data for quality improvement, and is it opt-in or opt-out?

Then make them put the answer in the BAA. A “we don’t train on your data” line on a marketing page is not enforceable. The same sentence in the permitted-uses clause is.

One more question, about accuracy

Not a HIPAA question, but it belongs on the same call. A JMIR Medical Informatics study of AI-generated clinical notes reviewed 7,545 notes and evaluated 356 of them in detail: 18% contained omissions, 11.5% contained hallucinations, and 9.3% contained accidental inclusions.

Ask the vendor what their own measured rates are and how they were measured. A vendor with no number has not looked.

The checklist, condensed

Run this on the call:

1. Send me your BAA today. (Then read the permitted-uses clause first.)
2. Who is your AI model provider, and do you have a BAA with them?
3. List every subcontractor that touches PHI.
4. Field-level or disk-level encryption at rest?
5. Do you connect through the PMS’s official API, and are you on their published vendor list?
6. Can I export a per-patient access log, including your own staff?
7. How many days from your discovery of a breach until you notify me?
8. Who pays for patient notification?
9. Retention in days, per data type. Backup expiry in days.
10. Is my data — including free-text notes — used for training or human review, and where is that written?

Any vendor that answers all ten without hedging has done the work. Any vendor that answers most of them with “we’re fully HIPAA compliant” has told you the one thing that carries no information at all.

Run the resulting BAA past your own counsel before you sign. This page is a list of questions, not a legal opinion — but the questions are the part most practices skip.