AI treatment plan generation: where the process breaks
AI treatment plan generation breaks not on the model but at the input: appointment plan preparation is still done by hand, from memory, and from scattered notes.
The doctor spends appointment time not on diagnosis and talking with the patient but on consolidating medical history, images, medication restrictions, and colleagues' notes into one readable document.
Manual assembly of the plan predictably loses details.
An allergy recorded at a previous appointment does not surface in a new one; a contraindication from the general dentist's report does not reach the prosthodontist; the dosage is carried over together with an outdated diagnosis.
Errors in the treatment plan are discovered during the intervention — when redoing it is most expensive.
The second part of the bottleneck is the discrepancy between specialists. The general dentist, prosthodontist, and implantologist each assemble the plan in their own format: one has structured fields, another free text, and a third a table.
Treatment plan automation is possible only after bringing the records to a common structure — diagnosis, stage, timeline, restrictions, patient consent.
While there is no structure, generation inserts into the plan what "sounds similar" and does not distinguish a rare case from a typical one: a patient with a comorbidity receives a template that the doctor edits from scratch.
Below we break down exactly where the process breaks — from the quality of source records to the doctor's review of the generated plan.
Implementation effect: preparation time and repeat visits
The implementation effect is measured not in general terms but in appointment minutes and the share of returns.
Therefore, before starting, we take baseline clinic metrics: average plan preparation time, the number of patients who returned due to an incomplete plan, and the load per doctor — we then compare the result with this baseline.
How much time the doctor frees up
Before implementation, the doctor manually consolidates the medical history, images, reports, and price list into one document — this takes 15–25 minutes of an appointment, and more for a complex case.
The system assembles a draft plan from the structured data in the chart and the clinic's templates, leaving the doctor to review and choose the tactics: 12–18 minutes per patient are freed up, and this time goes to talking with the patient rather than filling out forms.
How the share of repeat visits decreases
A return is most often caused by a plan without stages, material options, and checkpoints: the patient leaves to think it over and comes back for clarification.
AI treatment plan generation assembles the mandatory blocks at once — diagnosis, stages, alternatives, timelines, and follow-up examinations; this framework relies on the minimum standard of informed consent of the World Dental Federation. The share of repeat visits due to an incomplete plan falls by 2–3 times — from 15–20% to 5–7%.
Standardization of treatment plans reduces variation between doctors: one patient's plan looks equally complete no matter who manages it.
The doctor's load shifts from paperwork to diagnosis and explanation, and we take metrics monthly — after two to three months it is clear whether the share of plans accepted by the patient without a second visit is growing, or whether the cause of returns lies elsewhere.
AI implementation options: cloud, local environment, hybrid
The three modes differ not in operating speed but in where medical data physically resides and who is responsible for access to it. This determines the amount of coordination with the clinic's security service and how quickly the system will go into operation.
Cloud environment: when it fits
Suitable for clinics without their own computing infrastructure: doctors work from the office or from a tablet, models are updated on the provider's side, and no on-site administrator is needed.
There is one limitation — part of the data goes outside the perimeter, so either de-identification of images or the patient's written consent to external processing is required. With several branches, this is the shortest path to launch.
Local environment: when it is mandatory
The system is deployed inside the clinic's network: the database, images, and models do not leave the perimeter.
This option is the only one possible when internal policy prohibits any external processing of medical data or when the regulator requires a complete access log for images.
The cost of the solution is a server with headroom for model computation and a specialist who monitors updates.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud | several sites, no own infrastructure, external processing is acceptable | dependence on communication channel, requirements for data transfer |
| Local | prohibition of external processing, strict access log for images | server capacity and on-site support are required |
| Hybrid | images are stored in the clinic, model updates and backups are in an external environment | more complex access scheme, an agreed key policy is required |
The hybrid scheme most often turns out to be the workable one: sensitive data remains in the clinic, while heavy computations are moved outside. We compare the clinic's requirements with these three options at the design stage — before the infrastructure is chosen.
Work stages: from data audit to handover to doctors
Implementation begins not with the model but with analyzing how the clinic manages data. We go from sources to the schema, then to configuration and testing on real clinical cases — this way, at each step it is clear what exactly affects plan quality.
Data and process audit
- Audit of data sources. We analyze patient charts, images, examination reports, price lists, and the service nomenclature: where there is labeling, where there are duplicates, where the same diagnosis is recorded differently. We also document what the doctor enters into the system and what remains outside it.
- Schema design. We agree on how the study, diagnosis, plan item, and treatment stage are linked, and by what rules the nomenclature is matched. The schema becomes a contract between the clinic and the system.
- System configuration. We connect sources, configure rules and reference books for the clinic's specializations, and set the plan output format and the constraints the system does not go beyond.
Validation on a control sample
- Control sample. We take histories analyzed manually by doctors and compare the proposed plan with their decision: what matched, what was missed, where extra was added.
- Analysis of discrepancies. We divide the causes into classes — incomplete data, disputed tactics, rule error — and fix what relates to the system rather than to medicine.
- Doctor training. We show how to read the system's output, how to make edits, and where to report disputed cases.
- Handover to doctors. We provide the regulations, roles, and update procedure — after that, the clinic runs the system on its own.
Regulations and documentation: what remains in the clinic after launch
A ready solution is not only a working service but also a set of documents by which the clinic operates it independently, without us. Below is what exactly is handed over and how it is structured.
Documentation set
- Description of treatment plan generation scenarios — which data the doctor confirms manually and which the system inserts itself, and on what basis.
- Scheme of exchange with the medical information system: which fields go outside, in what form, and what to do if data diverges.
- Instructions for staff — separate ones for the administrator, doctor, and manager, with analysis of typical errors and the boundaries of using prompts.
- Operating regulations: who updates protocol templates and service reference books, and how changes are agreed.
- System passport — composition of components, external dependencies, update and rollback procedure to the previous version.
- Support procedure: contact channels, response time by incident class, responsible persons on both sides.
Access rights and activity log
Roles are delineated on the principle of least privilege: the doctor sees the plans of their patients, the administrator sees only the schedule and statuses, and the manager sees a summary without the contents of charts.
The setup of rights is described in the document, so a new employee is onboarded into the system by your administrator, not by our team.
The activity log records who opened the plan, who changed what, and what data went to external services — with timestamps and no possibility of retroactive editing.
The export is in a standard format, so verification or internal audit takes minutes rather than days of correspondence with the contractor. Access to de-identified data for model retraining is granted separately and formalized by a written decision of the clinic.
Case study: a clinic network halved appointment time
A network of dental clinics with several branches came with a clear pain point: the treatment plan was assembled manually right during the appointment and looked different for each doctor.
We took their own clinical protocols and current service list as the basis, and implemented branch by branch — from one office to the others, so that before-and-after metrics were calculated on the same sample of appointments.
Situation before implementation
The doctor typed up the plan at the end of the appointment: stages, materials, timelines, alternatives.
Diagnosis wordings diverged from ICD-10 codes, line items in the estimate sometimes did not match the service list, and the administrator sent clarifications to the patient after the visit.
Every second chart was returned for rewriting after approval, and some patients did not reach treatment start — the plan looked raw.
What changed after
The system assembles a draft plan from confirmed data: medical history, images, and the selected protocol. The doctor reviews and edits the finished product, while wordings and codes come from a single reference book — the plan reads the same across all branches.
| Metric | Before | After |
|---|---|---|
| Plan preparation during appointment | 20–25 minutes | 8–10 minutes |
| Charts rewritten after approval | every second | every eighth |
| Plans brought to treatment start | about 60% | about 80% |
| Wordings between branches | different for each doctor | one reference book |
A separate class of refusals that was not even tracked before was closed: if an item found no match in the service list, the system left the field empty, and this surfaced after the patient had left.
Now such a case is highlighted to the doctor during the appointment along with the closest correct option. After a quarter, the share of rewritten plans stopped growing, and the bottleneck shifted from paperwork to room utilization.
What to do if the clinic already has its own records system?
The clinic's records system is the schedule, charts, inventory, and billing; changing it just for treatment plan generation is organizationally difficult.
Therefore, your own information system remains the core, and a module appears next to it: it reads the medical history and images and returns a draft plan with justifications. The connection method depends on what data the system exposes today.
Exchange via exports is the simplest option. The system provides the medical history, diagnoses, and examination results as a file on a schedule or on an appointment event, the module returns a plan variant, and only what the doctor confirms goes into the chart.
The limitations are honest: there is a delay between the appointment and the finished plan, and the service and code reference books are synchronized separately.
If the system is open to external requests, an intermediate layer is placed between it and the module.
It maintains a message queue, brings the service nomenclature and units of measurement to a unified form, and caches reference books so as not to hit the records environment at every step. The cost of the scheme is agreed read and write permissions and maintenance of the layer itself.
A phased transition removes risk. First, the module works in prompt mode next to the system, and the doctor checks the result against the usual order; then writing to the chart is enabled, and after that, automation of typical protocols.
We check compatibility on a test environment with a copy of the data, so live recording does not suffer, and disabling recording returns the clinic to the previous order without losing history.
Technical concerns: patient data, responsibility, integrations
Objections to a treatment plan generation system usually come down to four: where patient data is stored, who is responsible for the prescription, how the correctness of the output is checked, and how it integrates into the clinic's current work.
None of them is resolved by promises — only by architecture, access regulations, and an explicit boundary of responsibility.
Below are direct answers to what is most often checked during technical project review.
Is patient data stored on your side?
A de-identified record goes into processing: only the fields needed to build the plan. The full medical history remains in the clinic, access to data is logged for each request, and rights are separated by role — the doctor, administrator, and engineer see different things.
Who is responsible for the prescription?
The doctor. The system prepares a draft: sequence of stages, materials, approximate timelines. The specialist confirms it, edits it, or rejects it — and only after their decision does the plan go to the patient. Responsibility for the clinical decision is not shifted to the algorithm.
How do you make sure the plan is correct?
We assemble a test set of clinical cases with reference analyses and run it on every model update. We look at the share of plans accepted by the doctor without edits and the share of critical discrepancies — it must be zero. The output is additionally limited by the allowed list of prescriptions and materials.
How does the system integrate into the clinic's records?
Exchange is carried out via HL7 FHIR — an open profile for medical data exchange, so records, schedules, and examination results are not transferred by hand.
If the records system does not support exchange, we install an intermediate layer and close the integration with a test environment before putting it into operation.
What if the solution does not take root?
The system lives as a separate service and does not replace the records environment. Shutdown means the doctor returns to the previous template: accumulated data is exported to the clinic in full, access is closed, and no traces remain in the production environment.
What is needed to start: we will discuss the task and come back with an estimate
To make the timeline estimate substantive rather than "plus or minus six months," we build the first conversation around your data and processes.
We need to understand how the treatment plan is formed now, where the doctor's time is lost, and what materials are already digitized.
We will discuss the task using your examples, analyze it from an engineering standpoint, and come back with a work plan: stages, the result of each stage, and what will be required from your side.
Useful to prepare for project start:
- 5–10 real treatment plans — they show the accepted structure, terminology, and what the doctor adds by hand.
- Data sources: where the images are stored (CBCT, OPG, photos), in what format the export from the MIS is, and whether there is programmatic access.
- Templates and clinical protocols of the clinic — the basis for generation and validation rules; without them the system produces generic text.
- Boundaries of responsibility: which decisions remain with the doctor, who signs the plan, and what cannot be suggested automatically.
- Integration points: where the result goes — as text into the chart, a document, or a structure for further calculation.
- Roles for validation: which doctors provide edits on the first versions and by what criteria we consider the result acceptable.
Describe the task in free form — we will come back with a timeline estimate and a work plan.