Integrating AI With SOE, R4 and Dentally
Most of the friction in a dental AI project has nothing to do with the AI. It sits in the gap between the clinical software you already run and the thing you have just bought a licence for. A caries detection model that reads a bitewing in 1.4 seconds is useless if the nurse has to export a JPEG to the desktop, drag it into a browser, wait, then describe the findings out loud so you can type them into the chart.
So the honest question is not “which AI is best”. It is: what does this product actually connect to, at which layer, and who owns the connection when it breaks on a Monday morning with 32 patients booked?
This page goes deep on that one question for the three systems that cover most of the UK market: Software of Excellence EXACT (SOE), Carestream’s R4+, and Dentally. For the wider decision framework, including how to shortlist vendors and what to pilot first, see the parent guide on choosing and integrating tools.
The layer that matters is imaging, not practice management
Practices assume radiograph AI integrates with their practice management system. It almost never does. It integrates with the imaging application, which is a separate piece of software that happens to be launched from a button inside the PMS.
Picture the chain in a typical surgery:
Dürr VistaScan sensor
-> DBSWIN / VistaSoft (imaging software, local PC or practice server)
-> image file written to \\SERVER\DBSWIN\Data\...
-> PMS (EXACT / R4+ / Dentally) holds a pointer + patient link
Your AI vendor needs to get at the middle layer. That is where the pixels are. The PMS only holds the patient identity and the pointer. This single fact explains most of what follows, including why a Dentally practice and an SOE practice can end up with almost identical AI deployments despite one being cloud and one being on-premise.
There are three realistic connection methods, and every vendor uses one of them:
| Method | How it works | Typical latency | Breaks when |
|---|---|---|---|
| Watched folder | AI agent monitors an export directory, picks up new images | 3 to 20 seconds | Someone changes the export path or a drive letter remaps |
| DICOM C-STORE | Imaging software sends to the AI as a DICOM node | 1 to 5 seconds | Firewall rules, port changes, AE title mismatch |
| Native plugin / TWAIN bridge | AI appears as a button or overlay inside the imaging app | under 2 seconds | Imaging software updates and breaks the hook |
Pearl’s Second Opinion, Overjet and VideaHealth all ship some combination of these. Ask which one you are getting, by name, before the demo ends.
Dentally: the one with a real API
Dentally is cloud-native and publishes developer documentation with OAuth-based credentials and webhooks, which makes it the easiest of the three to build against. If a vendor tells you they integrate with Dentally, that claim is checkable: ask for the scopes they request and what they do with them.
What that buys you in practice is mostly front-desk and triage automation rather than radiograph reading. A booking assistant can read availability, create an appointment, and write a note back to the patient record without anyone touching a keyboard. That is genuinely valuable, and it is the category where integration depth actually changes the product.
A realistic payload for an AI booking agent creating an appointment looks like this:
{
"appointment": {
"patient_id": 48213,
"practitioner_id": 17,
"start_time": "2026-10-14T09:20:00+01:00",
"finish_time": "2026-10-14T09:40:00+01:00",
"reason": "Emergency - upper right, pain on biting, 3 days",
"notes": "Triaged by AI assistant. Patient reports no swelling, no fever."
}
}
Two things to notice. The reason field is free text, so your triage bot’s output quality is entirely a prompt and policy question, not an integration question. And the appointment length was chosen by something: find out whether that is a fixed rule, a per-reason lookup table, or a model guessing. A model guessing 20 minutes for what turns out to be an extraction will cost you more than the software saves.
For imaging on Dentally, you are back to the chain above. Dentally hands off to whatever imaging software sits on the surgery PC, so a Pearl or Overjet deployment in a Dentally practice is a Windows agent watching Romexis or CS Imaging, not an API integration at all.
SOE EXACT: partner programme, patch windows, and a server you own
EXACT runs on a server in your building. That has one advantage worth stating plainly: the images never have to leave the premises unless you decide they should. Several AI vendors now offer on-premise inference for exactly this reason, and for an NHS practice nervous about patient data leaving the estate, it removes an entire chapter of the DPIA.
Integration with EXACT itself is gated through Software of Excellence’s partner arrangements rather than an open public API. The practical consequence: if a vendor says “we integrate with SOE”, press on what that means. Writing charting codes back into EXACT is a different and much harder claim than launching alongside it.
Here is the thing that catches practices out. EXACT updates on its own schedule, and a bridged integration that hooks the imaging launch sequence can stop working after a version bump. One four-surgery practice in the Midlands lost AI overlays for nine working days after an update, because the AI agent was watching a path that the new version no longer wrote to:
2026-03-09 08:41:12 WARN watcher: path not found
\\EXACTSRV\ExactImages\Export\
2026-03-09 08:41:12 INFO 0 images processed in last 24h
Nobody read the log. The nurses assumed the AI was quiet because the images were clean. Ask your vendor what alerting exists when throughput drops to zero, and get it sent to a human email address, not a dashboard nobody opens.
R4+: SQL Server underneath, CS Imaging alongside
R4+ pairs most naturally with Carestream’s own CS Imaging, and that pairing is the smoothest radiograph AI path of the three systems. CS Imaging speaks DICOM, which means a vendor can be configured as a destination node and receive images the moment they are captured, with no folder watching and no file format guesswork.
A working configuration looks roughly like:
AE Title: PEARL_SO
Host: 192.168.1.44
Port: 11112
Transfer: Implicit VR Little Endian
Auto-send: On capture, all intraoral
Set Auto-send to “on capture” rather than “on save” if your nurses habitually retake. Otherwise you pay per image for radiographs that get binned 20 seconds later, and if your contract is volume-based that adds up faster than you would expect.
Because R4+ sits on SQL Server, some vendors offer read-only reporting integrations that query the database directly for recall lists, failed-to-attend patterns or treatment plan conversion. Useful, and cheap to trial. Insist on read-only credentials in writing and confirm your support contract with Carestream is not voided by third-party database access.
A worked example: four surgeries, mixed NHS and private
Take a practice running four surgeries, three NHS-weighted and one private, on R4+ with CS 8100 units and VistaScan phosphor plates.
Radiograph volume: roughly 5,800 intraoral images a year across the four chairs. At an indicative UK licence of £150 per surgery per month, that is £7,200 a year, or about £1.24 per image. Indicative is doing real work in that sentence: quotes in 2025 and 2026 have ranged from roughly £80 to £250 per surgery per month depending on term length and whether the deal is bundled with a sensor purchase. Get yours in writing with the renewal uplift capped.
Now the return side, and be sceptical here. Vendor case studies often claim two minutes saved per exam. Honest observation in UK practices suggests the AI adds perhaps 10 to 15 seconds per exam for the clinician to review the overlay, and saves time only when it changes a conversation: a patient who accepts the interproximal restoration because they can see the annotated lesion rather than hearing about it.
Model it that way instead. If treatment plan acceptance on private restorative work moves from 61% to 68% on a base of 340 plans a year at an average £280, that is roughly 24 extra accepted plans and about £6,700 of additional revenue. Against £7,200 of licence, that is not yet a win. Add the medico-legal value of a documented second read and the picture shifts, but you should be the one deciding whether it shifts far enough, not the salesperson.
What integration will not fix
Charting write-back is the honest sticking point. Very few radiograph AI products write findings into the odontogram in EXACT, R4+ or Dentally, because the code mappings are practice-specific and the clinical liability of an automated chart entry is uncomfortable. You will still type. Budget for that.
FP17 submission is untouched by any of this. No radiograph AI currently populates a Band, a UDA count, or a Compass claim, and any vendor implying otherwise is describing a roadmap, not a product.
Your governance obligations do not move either. A radiograph AI that informs diagnosis is a medical device under UK MDR, so check for UKCA or CE marking and the class, ask whether the supplier has completed DCB0129 as manufacturer, and complete your own DCB0160 clinical safety case for deployment. If the tool touches patient data, a DPIA is not optional and your DSPT submission will need updating.
Sequencing the first ninety days
Run one surgery, not four. Pick the chair with the most reliable nurse and the fewest software oddities, install there, and leave it for six weeks before touching anything else. Measure throughput weekly, using the vendor’s own dashboard plus a manual count on one day, because those two numbers disagree more often than they should.
Week seven is when you find out whether the thing survives contact with a Monday. Book your PMS supplier’s update window deliberately inside the pilot rather than after it, so you discover a breakage while you still have the leverage of an unsigned three-year contract sitting on the desk.