Dental Board Rules and Clinical AI: How State Practice Acts Constrain What an Agent May Recommend
You probably think of clinical-AI compliance as a HIPAA problem — a matter of business associate agreements, encryption at rest, and knowing exactly where the protected health information lands. However, the rule most likely to stop your agent in production is not written anywhere in HIPAA; it lives in your state dental practice act.
HIPAA governs the data. Your state's dental practice act governs the decision — and a clinical agent is, by definition, in the business of decisions.
This is the compliance frontier most practices have not mapped yet. They cleared the HIPAA bar, signed the BAA with their model provider, and assumed the legal work was done — when a second and entirely separate body of law was waiting the whole time.
Practice acts and HIPAA are separate legal axes. HIPAA governs how patient data is stored and shared; the practice act governs who is licensed to diagnose, plan treatment, and prescribe — exactly what a clinical agent touches.
Why HIPAA Compliance Does Not Make Your Agent Legal
HIPAA and the Security Rule ask a narrow question: is the PHI protected in transit, at rest, and in the hands of the right people? Get that right — the BAA, the KMS keys, the audit logs — and you have satisfied HIPAA, and nothing more.
The practice act asks a different question entirely: who is permitted to practice dentistry, and what does "practicing dentistry" include? In nearly every state, that statutory definition covers diagnosis, treatment planning, surgery, and the prescription of drugs for dental conditions — the exact outputs a clinical agent is built to produce.
That is why we run the compliance argument before the model-quality argument, and why the HIPAA obligations for clinical AI are only half the picture. A caries-detection model can post state-of-the-art recall and still be deployed illegally if it hands a patient a diagnosis no licensed dentist ever signed.
| Dimension | HIPAA | State Dental Practice Act |
|---|---|---|
| What it governs | How PHI is stored, transmitted, and shared | Who may diagnose, plan treatment, and prescribe |
| The core question | Is the data protected and access controlled? | Is a licensed dentist making the clinical decision? |
| Who enforces | HHS Office for Civil Rights | The state dental board |
| What an AI violation looks like | Breach notification, OCR fine | Cease-and-desist, license exposure, unlicensed-practice charge |
Keep in mind that the two regimes fail in different ways. A HIPAA violation looks like a breach notification and an OCR fine; a practice-act violation looks like a cease-and-desist from the dental board, individual license exposure for the supervising dentist, and, in the worst case, a charge of aiding the unlicensed practice of dentistry.
What "The Practice of Dentistry" Actually Reserves to a License
Read the Illinois Dental Practice Act, or California's, or the Texas Occupations Code, and you will find the same core reservation: diagnosis, treatment planning, and prescribing are acts that only a licensed dentist may perform. The license attaches to a person, and an AI is not a person who can hold one.
This is the crux of the unlicensed-practice risk. An output that reads "irreversible pulpitis on #30, indicated for root canal therapy" is a diagnosis and a treatment plan — and if the software, rather than a licensed dentist, is the one making that call, the board can treat it as the practice of dentistry by an unlicensed party.
An AI holds no dental license, so any output framed as a diagnosis or a treatment decision can be read as the unlicensed practice of dentistry. Framing it as decision support for a licensed dentist is what keeps it lawful.
The escape hatch is well established in medicine: clinical decision support. The FDA has cleared dental AI — caries and radiograph tools like Overjet and Pearl — specifically as detection aids that inform a clinician, not as autonomous diagnosticians.
The legal load in that distinction is carried entirely by who decides. The agent surfaces the finding; the licensed dentist reviews it, agrees or overrides, and owns the diagnosis — which is why our caries detection agent presents every finding as a candidate for clinician review rather than a settled call.
The Line Between What an Agent May Suggest and What a Dentist Must Decide
Once you accept that decision authority is the hinge, the design problem gets concrete. For every output your agent can produce, you have to know which side of the line it sits on — a suggestion the dentist is free to take, or a decision the dentist is legally required to make.
| The agent may suggest | The licensed dentist must decide |
|---|---|
| Detect caries or flag a radiographic anomaly | Diagnose the condition |
| Draft treatment options with CDT codes | Select and approve the treatment plan |
| Compose a draft prescription order | Prescribe and sign |
| Assemble a consent summary | Obtain informed consent |
| Compute risk scores and surface data | Own the clinical judgment of record |
An agent may detect, flag, quantify, and draft options. A licensed dentist must diagnose, choose the treatment plan, prescribe, and obtain informed consent — and must be the named decider of record for each.
Note that prescribing is the brightest line of them all. Only a licensed dentist may prescribe, and controlled substances add DEA registration and state controlled-substance rules on top — so an agent that drafts an antibiotic or analgesic order must route it to a licensed prescriber and can never be the prescriber itself.
Informed consent sits on the same side of the line. The consent conversation is a clinical duty owned by the dentist, which is why our informed consent workflows position the agent as a drafting and documentation aid, never as the party that obtains the consent.
Corporate Practice of Dentistry — The Constraint DSOs Keep Missing
There is a second scope doctrine that trips up group practices specifically: the corporate practice of dentistry. In many states, only a licensed dentist — or a dentist-owned professional entity — may make or direct clinical decisions, and a non-dentist management company may not.
This matters the moment a DSO's technology layer starts producing clinical outputs. If the agent lives in the management company's stack and effectively makes the clinical call, the board can read that as a non-licensee directing clinical judgment — a corporate-practice violation independent of any HIPAA or scope question.
In corporate-practice-of-dentistry states, only a licensed dentist may direct clinical judgment. A DSO's software layer cannot be the clinical decider; the agent must route every clinical call to a licensed dentist.
The architectural consequence is specific. The licensed dentist of record — a named individual, not "the platform" — has to be the one who accepts each clinical recommendation, and your audit trail has to prove it after the fact.
Fifty States, Fifty Scope Maps — Schema Drift at the Regulatory Layer
If you operate in one state, you can read one statute and encode it once. The moment you cross a state line, you are dealing with schema drift at the regulatory layer — the same clinical output that is compliant in one state is a violation in the next.
Supervision levels are the clearest example. States define direct, indirect, general, and personal supervision differently, and what a dental hygienist or expanded-function assistant may do under each varies — so an agent that recommends a hygienist perform a procedure has to know the practicing dentist's state before it opens its mouth.
Supervision levels, hygienist scope, and teledentistry rules differ in every state. A multi-state deployment needs a per-location policy layer that maps each clinical output to the practicing dentist's own state.
Teledentistry adds another axis. Several states require an in-person or synchronous exam before certain diagnoses or prescriptions are valid, which means the same agent output can be lawful in an office and unlawful in an asynchronous remote flow within the same organization.
How Do You Architect an Agent That Respects a Practice Act?
The good news — this is a tractable systems problem, not a reason to abandon clinical AI. It comes down to treating scope of practice as a first-class policy layer, the same way you already treat PHI handling.
Start at the tool registry. Every tool your agent can call gets classified as administrative or clinical, and the clinical ones — draft-diagnosis, recommend-treatment-plan, draft-prescription — are flagged as requiring licensed sign-off before their output ever becomes an action.
Then make human-in-the-loop mandatory, not optional, on that clinical set. The agent's clinical outputs should be emitted as candidates marked "for clinician review," and a named licensed dentist has to accept, edit, or reject each one before it enters the record — which your clinical validation suite should test as explicitly as it tests model accuracy.
Wrap that in a state-aware policy layer. The agent needs the practicing location's state on every request so it can apply the correct scope map — supervision rules, hygienist scope, teledentistry constraints — instead of a single hard-coded default.
Finally, make the audit trail name a person. For every clinical output, the log has to answer "which licensed dentist was the decider of record?" — because when the board or a plaintiff's attorney asks, "the model recommended it" is not an answer that protects anyone.
This is also where the administrative-versus-clinical split pays off. Scheduling, insurance verification, and note summarization sit largely outside the practice act's reach, so those agents can run with far lighter human-in-the-loop than anything that touches diagnosis, treatment planning, or prescribing.
The Compliance Frontier Practices Have Not Mapped Yet
All of this adds up to a classification problem most practices have not run: for every clinical output your agent produces, in every state you operate, is it a suggestion to a licensed decider or an autonomous decision? Get that mapping wrong and you are not exposed to a data fine — you are exposed to a dental board.
The organizations that will deploy clinical agents at scale are the ones that treat the practice act as a design input from day one, next to the model and next to the PHI boundary. The ones that bolt it on after a board inquiry will spend the difference in legal fees and license risk.
If you are scoping a clinical agent and have not yet mapped which of its outputs cross into diagnosis, treatment planning, or prescribing, NexV builds and operates HIPAA-grade dental AI across multi-state group practices every week. Reach out for a working session — we will classify your agent's outputs against your states' practice acts, mark the ones that require licensed sign-off, and leave you with a scope-of-practice policy layer you can deploy.
Frequently Asked Questions
Is a dental practice act the same as HIPAA?
No. HIPAA protects patient data; a dental practice act defines who may practice dentistry — diagnose, plan treatment, and prescribe. An AI can satisfy HIPAA and still violate the practice act.
Can a clinical AI legally diagnose a patient?
Not on its own. Diagnosis is reserved to licensed dentists, so the AI may surface and quantify findings, but a licensed dentist must review, confirm, and own the diagnosis as the decider of record.
Can an AI agent write a prescription in dentistry?
No. Only a licensed dentist may prescribe, and controlled substances add DEA and state rules. An agent may draft an order, but it must route to a licensed prescriber who reviews and signs it.
What is the corporate practice of dentistry doctrine?
In many states, only a licensed dentist may direct clinical decisions, not a non-dentist owner or management company. A DSO's software layer cannot be the clinical decider — the licensed dentist must be.
Do practice-act rules change across states?
Yes. Supervision levels, hygienist scope, and teledentistry requirements vary by state, so a multi-state agent needs a per-location policy layer that applies the practicing dentist's own state rules.