AI Dental X-Ray Analysis Software: What to Check Before You Buy — Clearance, Detection Thresholds, and Sensor Compatibility

Search for ai dental xray analysis software and nearly every result on the first page is a vendor selling one. The clinical claims on those pages are usually accurate and almost never comparable, because each one reports a different metric, computed on a different image set, at an operating point nobody names.

The consequence shows up in the operatory rather than the browser. Two products both advertising 95% sensitivity on interproximal caries can generate very different false-positive counts per bitewing, depending entirely on where the confidence threshold sits when the software ships to you.

What follows is a neutral evaluation framework — what to pull from the FDA 510(k) record, how to read a detection threshold as a dial rather than a score, which sensor and practice-management details quietly break integrations, and what a pilot has to measure. None of it requires a data science team.

Most of it requires asking for documents the vendor already has. And noticing which of those requests get answered slowly.

What The FDA 510(k) Record Actually Tells You

Any AI product that marks pathology on a dental radiograph in the United States is a regulated medical device, and the ones worth your time have a 510(k) clearance on file. That clearance is public, searchable by K-number in the FDA database, and it is the single most useful document in the entire evaluation.

Ask for the K-number in writing. A vendor that responds with a marketing PDF instead of a number has told you something.

The indications-for-use statement is where the specificity lives. It names the image modalities the device was cleared for, the findings it may mark, the patient population, and the reading mode.

Here is what to confirm that statement actually says, item by item:

• Modality. Bitewing and periapical clearance does not extend to panoramic images, and neither extends to CBCT volumes. Confirm which clearance covers the radiographs you take most.
• Findings. A device cleared to detect caries has not thereby been cleared to measure crestal bone levels or flag periapical radiolucency. Each finding class is its own claim, supported by its own data.
• Reading mode. Adjunctive means the dentist reads first and the software marks afterward; concurrent means both happen together. The distinction changes your workflow and your documentation.
• Population. Most dental radiograph AI is cleared for adult dentition, and pediatric clearance is a separate matter. If you run a heavy pediatric schedule, ask directly.
• Predicate and performance data. The 510(k) summary lists the predicate device and the standalone performance study. Read the sample size, the reference standard, and who established ground truth.

That last item deserves emphasis. Ground truth in caries detection studies is frequently established by a consensus panel of readers rather than by histology, which makes the headline number a measure of agreement with expert dentists rather than a measure of disease.

Keep in mind that clearance is a floor. It establishes substantial equivalence to a predicate for a stated use, and it says nothing about whether the software performs on your sensors, in your operatories, at the threshold your vendor ships.

State regulation stacks on top of the federal layer, and several boards have issued guidance on AI-assisted diagnosis and documentation — we cover that terrain in dental board rules for clinical AI. The underlying detection literature is unpacked in our post on AI caries detection.

Where Your Radiographs Go During A Demo

A dental radiograph becomes protected health information the moment it carries a patient identifier, and the DICOM header carries several by default — name, date of birth, patient ID, often the referring provider. Any vendor that processes those images is a business associate under HIPAA, which means a signed BAA before the first upload.

That much is table stakes. The questions that separate vendors come after it.

• Retention and retraining. Ask in writing whether your images are retained after inference and whether they are used to train or fine-tune models. A de-identified-for-product-improvement clause deserves a careful read.
• Subprocessors. Most clinical inference runs on Amazon Bedrock or a self-hosted vision model on GPU instances, and the patterns are covered in Bedrock for clinical AI. Get the subprocessor list, the region, and confirmation that a BAA covers each hop.
• Audit trail. You want a per-image record of what was sent, when, by which user, and what came back. CloudTrail-grade logging is the standard to ask for.
• Deletion. Ask what happens to your images on the day you terminate. Thirty days is a common answer; indefinite retention in de-identified form is a materially different one.

Note that the demo itself is the most common leak. Vendors routinely request a batch of your real radiographs to show the software working, and that batch is PHI moving to a third party before any contract exists.

De-identify the demo set or sign the BAA first. Our fuller treatment of the architecture sits in HIPAA-compliant clinical AI for dental practices.

Sensitivity And Specificity Are One Dial

This is the section vendors are least eager to have. Every detection model produces a confidence score per candidate finding, and the software draws a mark when that score clears a configured threshold.

Move the threshold down and sensitivity rises while specificity falls. Move it up and the reverse happens — same model, same weights, entirely different clinical behavior.

Which is why a single advertised number tells you very little. A 95% sensitivity claim is one point on a curve, and the point that governs your day is the one the software ships with.

The arithmetic is worth doing before the pilot rather than during it. Consider a practice running 20 hygiene visits a day with four bitewings each, and somewhere north of 30 scoreable interproximal surfaces per patient — call it 600 surface-level evaluations a day.

At 95% sensitivity and 92% specificity, a plausible operating point for a cleared caries detector, the false positives come off the healthy surfaces, which are the overwhelming majority. If surface-level prevalence runs about 5%, that is roughly 30 diseased surfaces and 570 healthy ones per day.

The model catches about 28 of the 30. It also marks about 46 healthy surfaces, which means roughly three of every five marks on the screen do not correspond to disease.

None of that makes the model defective. Low prevalence does this to every screening tool, which is why positive predictive value — rather than sensitivity — governs how the software feels chairside.

What's more, the number moves with your patient population. A pediatric or high-caries-risk panel raises prevalence and therefore raises PPV, while a stable low-risk recall population does the opposite.

Ask three things and get the answers in writing. What is the default threshold, is it adjustable per practice or per provider, and what are sensitivity and specificity at each setting on the vendor's own validation set?

A vendor that can produce a full ROC curve has done the work. One that answers only with AUC is describing the model's ceiling rather than its behavior.

Our framework for building the measurement harness around all of this is in clinical AI evaluation suites.

Sensor Compatibility Is Where Pilots Quietly Fail

Detection models learn a pixel distribution. Your intraoral sensor, its driver, and its enhancement settings determine that distribution, and they vary far more than most buyers expect.

A DEXIS Titanium, a Schick 33, a Carestream RVG 6200, a Planmeca ProSensor, and a phosphor plate scanned on a ScanX all produce anatomically similar images with materially different noise floors, sharpening profiles, contrast curves, and effective resolution in line pairs per millimeter. Layer on the fact that most sensor drivers apply an enhancement filter before the image is ever written to disk, and what the model sees is a processed image rather than a raw capture.

Accordingly, sensor-agnostic is a claim to test rather than accept. The failure mode here is subtle: the software runs, produces marks, and quietly performs a few points worse than the validation data promised.

Here is what to confirm before the contract, and what to force into the pilot:

• Named sensor validation. Ask which sensor makes and models appear in the vendor's validation set, by name and by image count. A design goal is not a test result.
• Enhancement settings. Confirm whether the software expects raw or processed images and whether your current driver preset matches. Some vendors specify a filter setting; most do not, which is its own answer.
• Phosphor plates. PSP images carry scan artifacts, plate scratches, and a different noise character than solid-state sensors. If you run plates in any operatory, require them in the pilot set.
• File format and transport. DICOM is the interoperable path, yet a large share of dental imaging still lives in proprietary databases and moves across TWAIN bridges. Establish which route your images take and who owns the failure when it breaks.
• Resolution floor. Ask for the minimum pixel dimensions and bit depth the model requires. Older sensors and downsampled exports fall below it more often than you would guess.

Then run a bench test. Two hundred of your own radiographs, drawn from every sensor in the building, scored before you sign anything.

The transport layer deserves its own attention, and we go deeper in DICOM interoperability for dental imaging and in AI radiograph analysis.

Where Do The Findings Land In The Chart?

Two very different products are sold under one category name. One draws boxes on the image inside a viewer, and the other writes structured findings into the patient record.

The first changes what the dentist sees. The second changes charting time, treatment planning, and every downstream report — and it is considerably harder to build.

So ask where the integration actually attaches. Dentrix, Eaglesoft, Open Dental, Curve, and Denticon each expose different surfaces, and integrates with Dentrix can mean anything from a launcher button to bidirectional writeback of provisional findings.

• Tooth numbering. Universal numbering and FDI two-digit notation are both in active use, and a mapping error puts a finding on the wrong tooth. Ask which notation the API speaks and how supernumeraries and primary dentition are handled.
• Surface codes. A caries finding is only chartable once it resolves to M, O, D, B, or L. Detection at the tooth level without surface resolution leaves the assistant doing the same work as before.
• Provisional versus signed. AI output should land as an unsigned proposed finding that a provider accepts or rejects. Anything writing directly into a signed chart entry is a documentation problem waiting to surface in an audit.
• Override capture. The rejections are the most valuable data you will own. Confirm that dismissals are logged with the image, the threshold, and the model version.
• Model-version pinning. Ask how you are notified when the model updates and whether you can stay pinned through a validation cycle. Silent updates invalidate every baseline the pilot established.

Model-version pinning is the item buyers forget. In fact, a vendor that ships a new detection model on a Tuesday without notice has changed your false-positive rate, and your hygiene team will feel it days before anyone can explain it.

The charting side of this is covered in AI dental charting, and the practice-management plumbing in Dentrix cloud migration.

What A Real Pilot Measures

Most dental AI pilots measure enthusiasm. They run three weeks, the doctor likes the overlays, and the contract gets signed on a feeling.

A pilot worth the disruption produces numbers you can defend in a partners' meeting. That means the design is fixed before day one, with a stated kill criterion.

Run it six to eight weeks, across every operator and every sensor. Fifteen hundred to two thousand scored radiographs is a defensible floor for a single location.

Furthermore, split the pilot into two arms. Retrospective scoring on archived images gives you clean statistics without workflow disruption, and a prospective arm tells you what the software does to a live schedule.

Track the arms separately. A tool can score beautifully on archived bitewings and still fail prospectively because it adds 90 seconds to every hygiene handoff.

Latency deserves separate treatment, and we give it that in chairside AI latency. The downstream economics — what a detection tool does to case presentation and to the practice P&L — are worked through in case acceptance rate and dental AI ROI.

Five Requests That Sort Vendors Quickly

Every item below is a document or a number a serious vendor already holds. The speed of the reply is itself a data point.

• The K-number and indications-for-use statement. Request the statement text itself, along with the standalone performance study and its ground-truth methodology.
• The ROC curve and default operating point. Sensitivity and specificity at the shipped threshold, plus whether that threshold is adjustable per provider.
• The validation set composition. Sensor makes and models by name and count, modality breakdown, and patient demographics.
• The BAA, subprocessor list, and retention policy. Including what happens to your images at termination and whether they train future models.
• A reference of comparable size and PMS. A three-location group on Open Dental learns very little from a 40-location DSO reference running Denticon.

All of it should arrive inside a week. A vendor who cannot produce clearance documentation quickly is a vendor whose sales motion has outrun its regulatory file.

Common Questions About AI Dental X-Ray Software

Scoping A Radiograph AI Evaluation

If you are running an evaluation across multiple locations and want a second set of eyes on the pilot design, the team at NexV builds and operates HIPAA-grade clinical AI across dental imaging, charting, and practice-management environments every week. Reach out for a working session — we will read the vendor's clearance file with you, design the over-read protocol and threshold sweep, and hand you a scoring sheet with a written kill criterion you can take to your partners.

Bring your sensor inventory and your practice-management version to the first call. Most of the design depends on those two facts.