Claude Treatment Plan Explanations for Dental Websites

AI treatment plan explanations built on Claude address a specific weakness in how dental groups communicate: the moment between the consultation and the patient's decision. A group running fourteen practices across the south of England might produce four hundred treatment plans a week. Each plan is clinically correct, priced correctly in the practice management system and printed on the group's template. Yet the quality of the explanation the patient receives depends entirely on which associate they saw, how full the diary was and whether a treatment coordinator was free that afternoon. Two patients with identical plans for an implant-retained bridge can leave with completely different understandings of what will happen and why.

For the group's clinical director this is a consistency problem, and for the finance director it is a conversion problem. Plan acceptance varies between practices by twenty percentage points or more, and much of that gap comes down to explanation quality rather than clinical need. The same inconsistency shows up in pre-visit preparation, where one practice's online form is thorough and another's still asks patients to bring a list of medicines on the day. Standardising this by hand means training every associate and every TCO to write the same way, which nobody has time to do.

Claude, integrated into the group's website and patient portal, gives every practice the same standard of preparation and explanation without asking clinicians to change how they work. It reads what the patient submitted before the visit and produces a consistent pre-visit brief. After the consultation it takes the plan the dentist has approved and writes the explanation the TCO would write if they had twenty unhurried minutes for every patient. Claude does not diagnose and does not decide treatment. It prepares the brief, explains the approved plan and routes anything unusual to a person; the dentist remains responsible for every clinical judgement.

Where Traditional Treatment Plan Communication Falls Short

The document a patient takes home is usually an estimate generated by the practice management system. It lists procedures by code and tooth, shows a total, and may add a paragraph of standard terms. It does not say why the lower left molar is being crowned rather than filled, why the hygiene appointments come first, or what the difference is between the two implant options the dentist mentioned. Those things were said in the chair, and by the time the patient is home they have blurred. A verbal explanation delivered once, under time pressure, to a person who is anxious and slightly numb is not a reliable channel.

Groups have tried to fix this with printed leaflets, template letters and TCO follow-up calls. Leaflets are generic and cannot reference the patient's own plan. Template letters need someone to fill them in, which takes the time the group was trying to save. TCO calls work well but reach only the highest-value cases. So most patients decide on the basis of the price and a vague recollection, and the associates with the best chairside manner have the best acceptance rates, regardless of the plan.

What Claude Adds to a Dental Treatment Plan Website

• Claude reads the dentist's plan, the pre-visit intake and the practice's own explanation standards, and writes a patient-specific explanation in the group's voice.

• It returns every result in a fixed JSON structure that the portal, the practice management system and the reporting layer can consume without human re-keying.

• It applies routing rules the group defines, so that plans needing extra consent steps, second opinions or finance conversations are directed to the right people.

Reading Plans and Intake Together

Claude is given the plan as line items, the intake answers the patient supplied before the visit, the dentist's short consultation note and the group's explanation guidelines. It combines these into one coherent narrative. If the intake mentioned a fear of injections and the plan includes an extraction, the explanation addresses that concern in the section about that visit. If the patient asked about cost spreading, the explanation mentions the group's finance options where the group's rules allow it.

The model works well with long context, so it can read the full guideline document rather than a summary of it. That matters for a group with detailed rules about how to describe private versus NHS options, how to phrase risks and what must never be promised. The rules go in once and apply to every practice.

Structured Output the Group Controls

The output is JSON, not prose, with fields the group defines: a short overview, one explanation per plan item, a suggested sequence of visits, a list of alternatives the dentist mentioned, questions the patient may wish to ask, and a costs block. Each field has a maximum length and a tone rule. A reviewer sees the same layout for every plan in every practice, which makes approval quick.

Structure also makes measurement possible. Because the explanation is broken into fields, the group can see which sections are most often edited by dentists, which alternatives lead to changed decisions and where explanations are too long. That feedback shapes the next revision of the guidelines and the prompt.

Routing to the Right Person

Some plans should not go straight from generation to the patient. Plans above a value threshold may require a TCO call. Plans involving sedation, general anaesthetic referral or a patient flagged as vulnerable may require a second clinician's check. Claude tags each plan with the conditions it detects; the group's own rules, held in the backend, decide who must approve it.

This is the pattern for anything regulated: Claude drafts and labels, people confirm. The dentist approves the clinical content, the TCO approves the financial content where the group requires it, and the patient receives an explanation only after those approvals are recorded. The audit trail shows every step.

Best Use Cases for Claude Treatment Plan Explanations

• Multi-site dental groups use Claude to bring every practice up to the same explanation standard without retraining associates.

• Implant and orthodontic centres benefit from long, staged plans being explained visit by visit with the alternatives set out clearly.

• Membership-plan practices use the same integration to explain what is covered, what is not and why a recommended item sits outside the plan.

Multi-Site Dental Groups

A group of ten to fifty practices has central clinical governance, a shared practice management platform and a marketing team that already owns the website. This is the ideal setting. Claude is integrated once, guidelines are written once, and every practice's plans flow through the same review screen. Acceptance rates, edit rates and time-to-explanation become comparable across sites for the first time.

The group can also adjust for local differences without forking the system. A practice with a large NHS list needs explanations that distinguish band charges clearly; a private-only practice needs a different costs block. These are configuration, not new prompts, and the central team controls them.

Implant and Orthodontic Centres

A full-arch implant plan or a two-year orthodontic course involves many visits, several decision points and a large sum of money. Patients frequently misunderstand the sequence, the healing periods or what happens if a stage is delayed. Claude writes the explanation as a timeline, one visit at a time, with the reason for each step and the point at which the patient can still change course.

Because the plan is staged, the explanation is regenerated when the plan changes. If the specialist revises the approach after a scan, the patient receives an updated explanation showing what changed and why, approved by the specialist, rather than a fresh estimate with no context.

Membership-Plan Practices

Practices that sell monthly membership plans field a constant stream of questions about coverage. When a dentist recommends a crown and the patient is on a plan that covers examinations and hygiene, the explanation needs to say plainly what is included, what is discounted and what is charged in full. Claude reads the plan terms and the treatment plan together and sets this out in the costs block.

The value is fewer surprised phone calls and fewer disputes at the desk. Reception can point to the written explanation the patient received and approved, and the practice's complaints log gets shorter.

Core Features of a Claude Treatment Plan Website

• The intake layer captures pre-visit information and, after the consultation, the dentist's approved plan and note.

• The intelligence layer sends plan, intake and guidelines to Claude and validates the structured explanation that comes back.

• The action layer runs approvals, delivers the explanation to the patient and reports on acceptance and edits across the group.

Intake and Plan Capture Layer

Patients complete a pre-visit form on the group's website or portal. Dentists enter the plan in the practice management system as usual; an integration reads it through the vendor's API or a scheduled export, so nobody types the plan twice. The dentist adds a short consultation note in the portal, ideally two or three sentences about what was discussed and which alternatives were offered.

This note is the most valuable input. It turns a list of codes into a story Claude can explain. Groups that make the note mandatory get noticeably better explanations, so the portal is designed to make it quick.

Intelligence and Structured Output Layer

The backend assembles a system prompt containing the group's guidelines, tone rules, prohibited phrases and JSON schema, then sends the plan, intake and note as the user message. Claude returns the structured explanation. The backend validates it, checks every field against length and vocabulary rules, and rejects anything that mentions a diagnosis, a guarantee or a treatment not in the plan.

Rejected outputs are not retried silently. They are logged and sent to a person, because a rejection usually means the input was unusual and worth a look. This keeps the model's role firmly on the drafting side of the line.

Approval, Delivery and Reporting Layer

The dentist sees the explanation beside the plan and approves or edits it. Where rules require, the TCO or a second clinician sees it next. On final approval the explanation is delivered to the patient through the portal, email or SMS link, and the approval record is stored with the version of the prompt and the model used.

The reporting dashboard shows, per practice and per clinician, how many explanations were sent, how quickly, how often they were edited and how acceptance changed. The clinical director uses it for governance and the finance director for forecasting.

Step-by-Step Integration Process

• Write the group's explanation guidelines and approval rules before touching the model.

• Design the dentist's note-and-approve journey so that it takes under two minutes per plan.

• Connect the backend to Claude, validate every output, and measure acceptance and edit rates from day one.

Step 1: Define Explanation Goals, Categories and Business Rules

The clinical director, a senior TCO and the compliance lead agree what a good explanation contains, what it must never say and which plans need extra approval. They also fix the plan categories: routine restorative, hygiene, cosmetic, implant, orthodontic, sedation. Each category can have its own tone and length rules.

The output of this step is a written guideline and a JSON schema. Both are versioned, and the guideline is written for people first so that clinicians can review it without reading a prompt.

Step 2: Design the User Journey for Dentists, TCOs and Patients

The dentist's journey must be short: plan appears, note is typed, explanation is generated, approve or edit. The TCO's journey adds the financial review where required. The patient's journey is a clean page on the group's website with the explanation, the costs and a way to ask a question or book the next visit.

Prototypes are tested with two or three practices before rollout. Their edits and complaints shape the final screens, and their acceptance figures become the baseline for measuring the group-wide launch.

Step 3: Connect Your Website Backend to Claude

A Node service, on Velo, Firebase or a container on Google Cloud, receives the plan and note, builds the prompt and calls the Anthropic Messages API. Keys stay server-side. Patient identifiers are replaced with a token before the call and restored afterwards, so the model sees the clinical content but not the name or date of birth.

A synthetic set of plans covering every category is run through the system before launch. Clinicians review the outputs and the guideline is adjusted until the edit rate on the synthetic set is low enough to trust.

Step 4: Save Results, Trigger Workflows and Keep Humans in Control

Validated explanations are saved with the plan, the approvals and the versions used. Rules trigger TCO tasks, second-clinician checks and, on approval, delivery to the patient. A plan that changes in the practice management system automatically marks its explanation as stale so that it cannot be sent until regenerated and re-approved.

At no point does the system send an explanation without a dentist's approval, and no clinical wording can be added by anyone who is not a registrant. These constraints are enforced in code and are part of the group's clinical governance documentation.

Step 5: Measure Acceptance and Improve Over Time

The group tracks acceptance rate, time from consultation to explanation, edit rate by field and patient questions raised through the portal. Quarterly, the clinical director reviews the most-edited fields and updates the guideline. The prompt is changed only when the guideline changes, and every change is tested against the synthetic set first.

Over time the guideline becomes the group's written standard for how treatment is explained, which is useful well beyond the AI system.

Security, Privacy, Cost Control and Long-Term Scalability

• Treatment plans contain special category health data, so UK GDPR requires a lawful basis, a DPIA and strict access control across the group.

• Tokenising patient identifiers before each API call and setting retention terms with the provider limit the data the model ever sees.

• Costs scale linearly with plan volume and remain small relative to the value of a single additional accepted plan.

A dental group is a data controller for every patient across every practice, and its practices are regulated by the Care Quality Commission in England, with registrants bound by General Dental Council standards on consent and record keeping. Introducing Claude as a processor means a data protection impact assessment, a processing agreement with the provider, and confirmation of where data is processed and for how long it is retained. Tokenising names and dates of birth before the API call reduces what leaves the group's systems, and encryption in transit and at rest is standard. Role-based access ensures that an associate in one practice cannot see another practice's plans, while the central team can see everything for governance.

Costs are easy to forecast. Each explanation is a single call with a few thousand tokens in and a bounded number out; even a group generating twenty thousand explanations a year spends a modest amount, and a monthly cap in the backend prevents runaway use. Scaling to new practices means adding a tenant with its own fee list, plan types and staff, while the guidelines and the integration stay central. Where the group holds ISO 27001 or Cyber Essentials Plus, the integration stays inside the existing perimeter and every access is logged.

Davydov Consulting scopes and builds treatment plan explanation systems for dental groups on their existing platforms, including Wix Studio and Velo, Node and Firebase on Google Cloud, WordPress and mobile apps tied to the practice management system. We write the schemas and guidelines with your clinical leads, keep dentists in control of every patient-facing word, and deliver something your team can run and adjust. If this sounds like a problem you are trying to solve, we would be happy to discuss it.