Integration in three calls.
- Drop the signed SDK into your viewer or planning module.
- Call a single C++ entry point with a volume buffer; receive a label buffer.
- Render in your existing pipeline. No Python, no cloud, no PHI leaves the workstation.
An embedded segmentation SDK for medical imaging.
differentiable_segmentations is a binary C++ inference library for CBCT image segmentation that medical-imaging OEMs license and ship inside their own clinical products, starting with more than 70 classes of dental cone-beam CT. The horizon is broader: we have been working on the fundamental problems of medical-imaging segmentation since before the current generation of deep-learning algorithms, and that is where our attention stays.
Next release
Version 3 of the SDK is targeting September 15, 2026 — same public API, same regulatory posture, broader capability.
Differentiable Solutions provides segmentation as a software component for OEMs and integrators. It is not a finished medical device and is not intended for direct clinical use.
Talk to salesWhat the SDK does today.
On dental cone-beam CT volumes, the SDK performs semantic segmentation across more than 70 classes in a single inference pass — teeth at FDI granularity, individual pulps, jawbone, mandibular canals, maxillary sinuses, pharynx, and dental work (bridges, crowns, implants), plus background.
Runs in-process inside the OEM's application — a library in your binary, not a container, service, or cloud call. No cloud, no PHI egress, no internet dependency at inference time.
GPU-accelerated on a single, modest NVIDIA workstation card (RTX A4000) — a full clinical CBCT in less than a minute of inference, no high-end card, no separate server or GPU cluster required, and faster still on newer hardware.
Cross-platform parity: Windows and Linux — same code path, same numerical envelope.
Native C++ — and if you prefer to consume it from Python, Java, or C#, we provide and support bindings for it.
Returns a label volume in the input geometry. The OEM owns rendering, measurement, reporting, and clinical interpretation.
Every structure, one pass.
A single inference labels the full dental and maxillofacial anatomy — teeth in FDI notation, individual pulps, the mandible and maxilla, nerve canals, sinuses and airway — across more than 70 classes in a single volume.
70+
anatomical classes segmented in a single inference pass.
Teeth32 classes
- Maxillary Right Central IncisorFDI 11
- Maxillary Right Lateral IncisorFDI 12
- Maxillary Right CanineFDI 13
- Maxillary Right First PremolarFDI 14
- Maxillary Right Second PremolarFDI 15
- Maxillary Right First MolarFDI 16
- Maxillary Right Second MolarFDI 17
- Maxillary Right Third MolarFDI 18
- Maxillary Left Central IncisorFDI 21
- Maxillary Left Lateral IncisorFDI 22
- Maxillary Left CanineFDI 23
- Maxillary Left First PremolarFDI 24
- Maxillary Left Second PremolarFDI 25
- Maxillary Left First MolarFDI 26
- Maxillary Left Second MolarFDI 27
- Maxillary Left Third MolarFDI 28
- Mandibular Left Central IncisorFDI 31
- Mandibular Left Lateral IncisorFDI 32
- Mandibular Left CanineFDI 33
- Mandibular Left First PremolarFDI 34
- Mandibular Left Second PremolarFDI 35
- Mandibular Left First MolarFDI 36
- Mandibular Left Second MolarFDI 37
- Mandibular Left Third MolarFDI 38
- Mandibular Right Central IncisorFDI 41
- Mandibular Right Lateral IncisorFDI 42
- Mandibular Right CanineFDI 43
- Mandibular Right First PremolarFDI 44
- Mandibular Right Second PremolarFDI 45
- Mandibular Right First MolarFDI 46
- Mandibular Right Second MolarFDI 47
- Mandibular Right Third MolarFDI 48
02
Build it yourself, or license it.
The hidden cost is not only software. A credible internal build needs a specialist team of around ten — senior C++/CUDA, 3D medical imaging, MLOps, medical-device QA, release engineering, and a regulatory and clinical program manager — months to assemble in Europe and seven figures a year in payroll before any code ships. A dossier-ready binary then adds another 24 to 30 months, with qualification renewed at every release. By the time an in-house effort clears that bar, we are already approaching our v3.
| Build in-house | License our SDK | |
|---|---|---|
| Time-to-market | 24 to 30 months before a dossier-ready binary | First integration in weeks; focus stays on your product |
| Regulatory dossier | Needs a quality lead plus ISO 13485 / IEC 62304 / ISO 14971 process evidence | Plug-in package: SOUP, model card, validation summary, IFU template |
| Dataset-licence chain | Dataset rights, provenance, and validation evidence stay with you | Ours, with provenance documentation for the OEM file |
| Cross-platform parity | Needs senior C++/CUDA, 3D imaging, MLOps, and release-engineering coverage | Drop-in binary SDK for Windows and Linux |
| Reproducibility | Each model, dependency, CUDA, driver, or OS revision reopens qualification | Versioned, traceable releases with maintained qualification support |
Why this is our work
Medical-imaging segmentation is what we do — full-time, end to end, for a living. We do this so our partners do not have to, and so they can put every hour they own into the product their customers buy from them.
How we are positioned
A different shape from the rest of the market.
The dental-CBCT AI landscape is crowded with clinician-facing apps, cloud upload portals, and single-feature AI assists bundled one at a time. We have deliberately built a different shape of product. Each contrast below is a design decision, not a marketing line.
Embedded SDK, not a clinician-facing app.
Most of the market ships finished viewers, reporting suites, or web portals to the clinic. We ship a binary C++ SDK that disappears inside the OEM's product. The brand on the screen, the workflow, and the clinical relationship stay with the OEM.
On-device inference, not cloud upload.
A common pattern is to upload CBCT volumes to a vendor cloud and receive results back over the network. Our inference runs on the OEM's workstation: no PHI egress, no internet dependency at inference time, and no third-party cloud sitting between the clinic and the result.
Broad anatomical layer, not a stack of single-feature assists.
Vendor catalogues commonly accumulate one AI assist at a time — a nerve-canal tracer here, a panoramic reconstruction there, a cephalometric tool somewhere else. We deliver more than 70 classes of the dental CBCT scene in a single inference pass, so the OEM builds workflows on top of a coherent segmentation layer instead of stitching point features together.
Component vendor, not finished medical device.
Several AI products on the market are themselves the cleared medical device, with their own clinical claims. We deliberately are not. The OEM is the legal manufacturer; we supply the dossier inputs, dataset-licence chain, and engineering documentation that make their CE MDR or FDA 510(k) submission tractable.
Vendor-neutral integration, not a single-device portfolio.
Some segmentation capabilities are tied to one imaging vendor's hardware or software portfolio. Our SDK is built to run inside whichever scanner, viewer, or planning suite the OEM already ships, on standard NVIDIA workstation GPUs.
Public benchmark comparisons against named vendors are available only under evaluation engagement and NDA. We do not make public accuracy claims against third parties.
Built for OEM economics, not for research demos.
PhD-level applied mathematics on the inside, a clean binary on the outside.
From first principles.
We work from the mathematics of medical volumes — geometry, numerical analysis, optimisation theory — up to the C++ that ships in the customer's installer. We do not glue libraries together and hope.
Regulatory leverage.
Our component-level dossier package drops into the OEM's CE MDR or FDA 510(k) file. We deliver the software-component documentation; the OEM carries the clinical claim. We are a component vendor, not a finished-device manufacturer — and we engineer accordingly.
No surprises in the customer's binary.
Embedded utility dependencies, encapsulated public API, signed Windows installers, reproducible Linux builds. The only thing the customer sees is a stable C++ contract and a sealed model artifact.
Integration in three calls.
A component vendor, by design.
A component vendor, by design.
We are a software component, not a finished medical device. The OEM is the legal manufacturer; we provide the dossier inputs, the dataset-licence chain, and the engineering documentation that makes their submission tractable.
Build medical imaging hardware or planning software?
If you are tired of evaluating research notebooks dressed up as products, we should talk.