Hybrid Dental Case Execution: dental case management with AI coworkers

Over several years of building Cympha we introduced a series of capabilities, each solving a problem a dental laboratory had put in front of us: a layer that classifies arriving files and proposes the next step on a case; automatic segmentation of a CBCT volume; an aligner designer that runs a case overnight with nobody present; a browser workspace a dentist can open a plan in without installing anything; and a desktop agent that connects a laboratory's own workstation to the case.

Taken one at a time, each of those is a feature. Taken together they are something more particular than "AI features", and the difference matters: they are AI tools embedded in case management. They do not sit beside the case waiting to be opened and operated. They are given jobs on the case, the way a person is given a job, and they hand the case back when they are done.

That arrangement turned out to be the valuable part — more valuable than any single capability in it, and the thing we found ourselves explaining over and over. This paper sets out the architecture underneath it, which we are bringing to the industry as a defined approach rather than a product description, and gives it a name: Hybrid Dental Case Execution (HDCE).

HDCE is dental case management in which an AI coworker is assigned work the same way a technician is — it takes the job, does it, and hands the case back. One record carries the case from the dentist's chair to the finished appliance, and the decisions along the way stay with people.

The term, the architecture and the implementation are all ours. We are publishing the definition so that others can build to it: a laboratory should be able to read the four conditions below and judge any system against them, including ours.

What the term means

Three words, each doing a job.

Hybrid means your team includes AI coworkers. An AI coworker is not a tool a technician opens and operates, and it is not a replacement for the technician. It is another name on the list you can give a job to: it takes some of the jobs on a case, the technician takes the rest, and both appear on the same record.

Dental case means the whole case, from the moment a dentist decides something needs making to the moment it is delivered and paid for — not a single step of it. Most dental software owns one step very well and knows nothing about the others.

Execution means the work actually happens inside the system rather than being launched from it. A case is given to someone — a technician, an outside designer, or a piece of software — and comes back finished. Anyone looking at the case can see who has it and what has been done.

Why it needs a name

Dental case management today usually means software that tracks a case: a portal, a status list, a place to attach files. People do the work and the system records that they did it.

Once software can genuinely take jobs on a case, that definition stops being enough. The questions a laboratory has to answer change. Not "where is this case", but "who or what should do this next, how much may it do on its own, and who is accountable for the result". A system designed to answer those is a different kind of system.

We named it because we kept having to explain it. We had already introduced Dental Case Lifecycle Management for the record that carries a case from the chair to delivery; HDCE is the next question, which that record makes it possible to ask — once the whole case is in one place, who does the work on it? Describing the answer as "AI features" each time understated it, and describing it as automation suggested something that runs rather than something you give a job to.

The rest of this paper is the background that makes the case for it, and the way we have implemented it.

Background: what a dental case is

A case starts when a dentist decides a patient needs something made — a surgical guide for an implant, a set of clear aligners, a crown, a denture.

From that moment a case is a package of things that have to travel together:

• the records — an intra-oral scan, a CBCT, photographs, sometimes an old model
• the prescription — what the dentist actually wants, and why
• the design work — somebody turns those records into something manufacturable
• the approval — the dentist looks at the plan and says yes, or asks for changes
• the manufacturing — printed, milled, or fabricated
• the delivery and the money — it goes back to the practice, and someone gets paid

Almost none of this happens in one building. The records are captured at a practice. The design is usually done at a dental laboratory, and increasingly by a freelance designer who may be in another country. Manufacturing may be a third place again. A single case can cross three organisations and five people before the patient sits back down.

What case management means in practice

Managing a case means being able to answer four questions at any moment:

• Where is it, and what is the next step?
• Who has it right now?
• What did the dentist ask for — in their words, not summarised in an email?
• What has already been done to it, and by whom?

That sounds administrative. In practice it is where most of the cost and nearly all of the frustration in the industry sits, because the tools involved were never designed to talk to each other.

A typical case today moves by email, WeTransfer or a shared drive, with the prescription written in the message body and the files attached. The scanner has its own portal. The design software is a desktop application that knows nothing about the practice. Chat happens somewhere else. Nothing records that the case exists as a single thing, so the only person who knows its true state is whoever happens to be holding it — and often not even them.

The common failures follow directly:

The case that sat still	A scan arrives with a problem nobody notices for two days. The dentist finds out by phoning to ask where it is.
The lost instruction	What the dentist wanted was in an email that the designer never saw, so the work comes back wrong and the whole case repeats.
The version question	Three files with similar names and no way to tell which one was approved.
The handoff cliff	Work goes to an outside designer and, for three days, the lab has no idea what is happening to it.

Who needs it

Dental laboratories feel it hardest, because they sit in the middle. A lab of thirty people might serve a hundred and eighty practices. Its binding constraint is almost never machines — it is trained designers, who take about a year to become useful and are extremely hard to recruit. Every hour a designer spends chasing a file, fixing a bad scan or re-doing a case because an instruction went missing is an hour not spent designing.

Dental practices feel it as unpredictability. They cannot tell a patient when something will be ready, they cannot see a plan before it is manufactured, and when they want a change they have to describe it in words and hope.

Freelance and outsourced designers feel it as context loss. They receive a folder and a paragraph, and have to reconstruct the clinical intent that was obvious to the dentist a week ago.

Larger groups and DSOs feel it as an absence of numbers. With cases moving through inboxes, nobody can say what the average turnaround is, which practices send the most work, or where the remakes come from.

Where AI can help in a dental case

"AI for dentistry" usually means one thing: automatic design. That is real, but it is a small part of the work in a case, and it is not the part that is most often the bottleneck. There are four distinct areas, and they have very different maturity.

1. Handling the data

Every case begins with files arriving, and a surprising amount of skilled time goes into simply dealing with them. Which of these twelve files is the upper arch? Is this scan complete enough to work from, or does it have a hole behind the last molar? This mesh has artefacts from the patient's tongue — can it be cleaned up, or does the practice need to re-scan?

Software is now good at all of this: classifying files by what they actually contain rather than what they are named, checking a scan for the defects that make it unusable, and repairing common problems automatically. It is unglamorous and it is the single cheapest hour to give back to a technician, because it requires no clinical judgement at all.

2. Doing design work

This is the part people mean. Three things are genuinely automatable today:

• Segmentation — separating bone, nerve canal and individual teeth out of a CBCT volume, which used to be an hour of manual work per case.
• Orthodontic setups — planning tooth movements and staging them into a series of aligners.
• Guide and appliance design — producing manufacturable geometry from a plan.

The important qualification is that automatic design produces a first pass. A person reviews it, adjusts what is wrong, and takes responsibility for it. What changes is the ratio: a designer who could finish two cases a day can finish several, because they are correcting rather than starting from nothing.

3. Finding and keeping the practices that send work

This one is almost always left out of discussions of AI in dentistry, and for a lab it can matter more than design.

A lab's revenue comes from a few hundred referring dentists, and the most common way to lose money is quietly: a practice that used to send four cases a month stops, and nobody notices for a quarter. The information needed to catch that already exists in the case history — who sends what, how often, how fast it came back, how many were remade. A general-purpose CRM cannot see any of it, because it does not know what a case is.

A system that holds the cases can notice the pattern and tell someone, and can draft the follow-up. Sending it is still a person's job, and should be.

4. Presenting the case

A plan is far easier to approve when you can see it. Showing a dentist a 3D plan in a browser — no software to install — removes the main reason approvals take days. The same applies to patients: a simulated result is a better consultation tool than any description, and software can now produce one from a photograph.

This is also where automation helps the lab's own communication: generating a clear, visual case presentation is work, and it is work that does not need a designer to do it.

What has to be true before any of it runs on its own

Most of the capabilities above exist as products you can buy today. The reason they rarely add up to much is that each one is a separate destination: you export a file, upload it somewhere, wait, download a result, and put it back. The software did the task; the person did the case.

For automation to actually remove work, four things have to be true of the system it runs inside. None of them is about the AI.

An AI coworker has to be given the job, the way a person is

Software that you run is a tool. For it to take work off people it has to be given a job the same way a person is: it appears in the queue, it has the case while it is working, it hands the case back when it is done, and all of that is visible to everyone else. That is what makes it a coworker rather than a feature.

This sounds like a detail. It is the difference between a lab manager thinking "I need to remember to run the segmentation" and a lab manager seeing that the case is already being worked on.

It has to say how sure it is

A result that arrives with no indication of quality can only be accepted or rejected in full, which means the only two settings available to a lab are "check everything" and "check nothing".

If each automated result arrives with a confidence score and a short reason, the lab can set a sensible rule instead: let simple file classification run on its own, but bring anything involving a design to a person, and bring anything the software is unsure about to a person regardless.

A person still signs it off

An AI coworker produces work. It does not take clinical responsibility, and it should not be able to. Approving a plan, releasing something to a patient, talking to the practice and settling payment stay with a named person.

The useful version of this is not a promise in a policy document. It is that an AI coworker is connected to the system in a way that simply does not include those actions: it can read the case and return work, and there is no approval button on its side of the connection to press.

Everything works from one record

None of the above is possible if the case lives in an inbox. There has to be one record of the case that the practice, the lab, the outside designer and the software all read from and write to. That record is what makes a handoff survive — including a handoff to software and back.

How Cympha implements it

Two things have to exist before any AI coworker is useful: a record for it to work on, and a way for it to reach the machine where the work runs. Those come first below, then the coworkers themselves, grouped by the four areas above.

The case record and the orchestration layer

A Cympha case holds the prescription, the files, the status, the approvals and the payment in one place, shared by the practice, the laboratory and any outside designer. Every event on it — a file uploaded, a status changed, a design approved — is written to the case history and published through a transactional outbox, so one event can set off the next step without anyone remembering to start it.

On top of that sits the orchestration layer, which is the coworker that works on the case itself rather than on the geometry:

• It classifies arriving files by what they contain rather than what they are called — an STL named upper_arch_final.stl is labelled as the upper arch without anyone tagging it.
• It proposes the next move — a status transition, a missing record to chase, a design that is ready for review.
• It never applies an irreversible change on its own. Every proposal carries a confidence score and a short reason and waits for the policy described below.

A bridge to the machine where the work runs

Where a coworker's work runs on a machine the laboratory owns, something has to connect that machine to the case. Generically this is a small, paired desktop application: it learns what work the laboratory has been given, watches the folders where scanners and CBCT units drop their exports, starts the local engine, and returns the result to the case. It reports that it is alive while a job runs, and the laboratory can revoke it at any time.

In Cympha this is the Cympha Agent. It sits in the system tray and does four of those jobs — watching the cloud for work, turning a scanner or CBCT export folder into a case in one click, uploading results back, and running the aligner design coworker.

Coworkers that handle the data

File classification is described above. Alongside it, a data coworker checks and repairs scans before anyone opens them, so a mesh with artefacts or a hole behind the last molar is fixed — or identified as needing a re-scan — at the point the case arrives rather than two days later. In Cympha this runs in the browser inside Cympha Studio, with nothing to install.

Coworkers that do design work

Two kinds are in production. They are entitled differently, because one is a capability in its own right and the other drives design software the laboratory already licenses — a distinction worth expecting of any design coworker.

A segmentation coworker	Separates bone, nerve canal and individual teeth out of a CBCT volume — about an hour of manual work per case. Sold as a capability of its own, because it needs no other software. In Cympha: CBCT Segmentation, a flat monthly add-on, started from the Agent's tray menu or by a job the case requested, running on the laboratory's own GPU workstation.
A design coworker	Takes a case end to end and unattended — planning, staging and producing the files a reviewer needs — in parallel, overnight. It drives a professional design engine, so it is entitled through the licence the laboratory already holds for that engine rather than bought separately. In Cympha: AlignerBot, which drives GuideMia OrthoPlus for orthodontic cases.

Both follow the same shape. The dentist's intent is extracted into a typed parameter set, the cleared engine runs from those parameters with nobody present, the result comes back to the case for review, and any correction returns as a structured adjustment rather than a sentence — so the second round is a re-run rather than a re-interpretation.

Coworkers that present the case

Presentation needs a viewer that asks nothing of the person looking. A 3D workspace that runs in the browser removes the install, the account and most of the delay in getting a plan approved — the dentist opens the plan, looks at it, and approves it or requests a change on the record.

In Cympha this is Cympha Studio: CBCT viewing and multi-planar reconstruction, cephalometric tracing, articulation simulation, smile design from a photograph, and mesh viewing and registration, all in a browser tab. The same material feeds patient-facing presentation, where a simulated result is a better consultation than any description — in Cympha, Cympha Presentation turns a case into a narrated video for a practice or a patient.

Finding and keeping the practices that send work

This is the newest of the four areas and the one we currently run on our own business rather than offer to laboratories. The mechanism is the one described earlier: the case history already knows who sends what, how often, how quickly it came back and how many were remade, so a quiet practice is detectable long before a quarter has passed. Applying it to a laboratory's own referral base is work in progress, not a shipping feature.

The laboratory sets the rules

For each kind of work, a laboratory decides whether an AI coworker's result may be applied automatically, the confidence below which it never is, and how many may be applied in a day. Those settings live in the laboratory's own settings screen, and the default is that nothing applies on its own. A laboratory typically lets file classification run unattended long before it lets anything touch a design.

What an AI coworker cannot do

The connection an AI coworker uses to reach Cympha can read a case, read and write files on it, and take or release a lock. That is the whole of it. There is no approval, no sharing with the practice, no messaging and no payment operation on that connection — so the clinical decision and everything that faces the customer stay with a named person, as a matter of how the system is built rather than a rule someone has to follow.

Why it runs on the laboratory's own computer

This is the part that surprises people, so it is worth stating plainly rather than leaving it in the small print. Automated design is not something we switch on in a data centre. It runs the laboratory's own professional design software, on a workstation it already owns, under a licence it already holds.

The practical consequence is that an AI coworker is something you equip, in the same way you equip a new designer with a computer. In exchange, nothing about the patient leaves the practice's and the laboratory's own systems, and the economics of running it stay with the laboratory.

Running on cleared design software

Where a coworker produces something that goes into a patient, the engine underneath it matters more than the automation around it. In Cympha the automated design runs on GuideMia, developed under an ISO 13485 quality system and including two FDA 510(k) cleared products — Implant Master for surgical guide design and OrthoPlus for orthodontics.

None of this requires the engine to be ours. Anything that accepts a task and returns a result can take a step on a case, which is what lets a laboratory keep the design software it already trusts.

What it is worth

To a laboratory

Capacity it cannot hire. A designer who spends their first hour on segmentation and mesh cleanup instead spends it on the part that needs judgement, and the overnight hours — when the building is empty and the workstation is idle — become productive. Fewer cases stall, because something is watching them. Fewer cases are remade, because the instruction travelled with the files.

To a dental practice

A date it can give the patient, a plan it can look at in 3D before anything is manufactured, and a change request that goes on the record instead of into an email. No software to install, and no account needed to approve a case.

To the people doing the work

This matters more than it is usually given credit for, because it decides whether any of it is adopted. A technician who believes an AI coworker is there to replace him will not use it properly. A technician who sees it produce a first pass that he corrects and signs off, with his name on the approval, will — because it makes his day better and his output larger.

To the business

Numbers that did not exist before: turnaround by practice, remakes by cause, how much work the AI coworkers did and how much of it was accepted unchanged. A case business run out of inboxes cannot produce those, and cannot manage what it cannot see.

In summary

Hybrid Dental Case Execution is dental case management in which an AI coworker is assigned work the same way a technician is, on one record, with the decisions kept with people. We introduced the term, developed the architecture, and implement it in Cympha — where the orchestration layer proposes the next step, coworkers handle data, run design unattended on the laboratory's own workstation and present the result in a browser, the laboratory sets how much runs on its own, and no coworker can approve anything.

The definition is open. Any system that assigns work to software the way it assigns work to a person, returns the result with a confidence, keeps the decisions with a named person and does all of it on one shared record is doing the same thing, whoever built it.

---

Cympha is a case management platform for dental practices and laboratories. Its automated design runs on GuideMia, which is developed under an ISO 13485 quality system and includes two FDA 510(k) cleared products. The Cympha platform itself is not a cleared medical device, and the clinical decision on every case remains with the clinician. See also our PLM reference architecture, which covers the product model and geometry layer in more technical detail.