What does "writeback" actually mean in a dental PMS integration?

Writeback means the software writes its finished output back into the practice management system on its own — a clinical note into the chart, an eligibility result onto the plan, a payment onto the ledger. Without it, the vendor only reads your data and hands you text to copy and paste. Both get described as "integration," so ask specifically whether the finished note lands in the chart or whether a human moves it.

How can I tell if a vendor uses direct database access to Open Dental?

Check Open Dental's published third-party vendor list. It sorts vendors into Authorized, Authorized in Transition, and Dangerous/Unknown — the last tier covers direct database access and unwhitelisted plugins. Roughly 90 vendors are listed Authorized, and listing is free via vendor.relations@opendental.com. A vendor who isn't listed and calls it unnecessary is telling you something about their architecture, not about paperwork.

What does Henry Schein One require of Dentrix Ascend integration vendors?

Vendors on the Henry Schein One API Exchange must be SOC 2 Type II certified and use OAuth 2.0. The Exchange lists 140+ authorized vendors. SOC 2 Type II means an outside auditor examined their security controls over a period of time, and OAuth 2.0 means the vendor authenticates through a token flow rather than storing and replaying your Ascend credentials.

Why do clinical notes get attributed differently on Open Dental than on Dentrix Ascend?

It's a data-model difference, not a vendor choice. Dentrix Ascend files a note against a real provider field. An Open Dental commlog has no provider field at all, so the provider's name has to be written into the body of the note itself. Any vendor claiming structured provider attribution on an Open Dental commlog is describing a field that does not exist in the schema.

What should I ask about audio retention when evaluating an AI scribe?

Ask per feature, not product-wide. Dictation and consent-gated recording are different paths with different storage. On our platform, dictation audio is held in memory only — never disk, S3, or a database — while transcript text is kept 24 hours so an interrupted recording can be resumed; separate opt-in recording features do store audio. A flat "we never store audio" claim across an entire product is a red flag.

"Integrates with Open Dental" Is Not One Thing: A Writeback Spectrum

Q: Does Open Dental have its own AI scribe?

No. Open Dental has no first-party AI clinical-note product. Bola AI is a native partner, not an Open Dental product. Open Dental does sell its own eServices bundle at $165/month covering Web Forms, Patient Portal, eReminders, eConfirmations, Integrated Texting, Web Sched, Secure Email, and ODMobile — so scribe pricing and patient-communication pricing are separate conversations.

Every AI vendor’s site says “integrates with Open Dental.” I have sat through demos where that one sentence described four completely different architectures, with completely different failure modes, and nobody on the sales side volunteered which one I was buying.

The word doing all the work is writeback. Either the finished product of the software lands in the patient’s chart on its own, or somebody on your team moves it there by hand. Those are not variations of the same feature. One of them is an integration. The other is a clipboard.

Here is the actual spectrum, what each tier costs you in reliability and support, and the four minutes of demo questions that tell you which one you’re looking at.

The four tiers, plainly

(a) Official API with two-way writeback. The vendor authenticates through the PMS company’s supported API, reads what it needs, and writes results back — a note into the chart, an eligibility result onto the insurance plan, a payment onto the ledger. When the PMS ships an update, the API contract holds. When something breaks, there is a vendor relationship and a support path that doesn’t start with “we don’t support that.”

(b) API read-only. The vendor uses the same official API but only pulls. It reads your schedule, your patient demographics, maybe procedure history — then produces output that lives in the vendor’s own web app. You copy. You paste. This is extremely common with AI scribes and it is not always disclosed. The demo looks identical to tier (a) right up until the last ten seconds, which is exactly why vendors end demos ten seconds early.

(c) HL7 or a bridge/middleware layer. A translation service sits between the vendor and your PMS. Sometimes that’s legitimate and necessary — Open Dental’s own eConnector is a supported local service. Sometimes it’s a third-party broker reselling access, which adds a company, a contract, and a BAA to your risk surface. Ask who operates the bridge and who you call at 7:40am when it stops.

(d) Direct database access or screen-scraping. The vendor connects straight to your MySQL database, or drives the PMS user interface with a robot, or installs an unwhitelisted plugin. It works until an update changes a table or moves a button. There is no contract behind it. And your PMS vendor may reasonably decline to support a database somebody else has been writing to.

Open Dental publishes a scoreboard. Read it.

This is the part most practices don’t know exists. Open Dental maintains a public third-party vendor list with explicit trust tiers: Authorized, Authorized in Transition, and Dangerous/Unknown — the last of which is where direct-database vendors and unwhitelisted plugins land. Roughly 90 vendors currently sit in the Authorized tier. Lassie and Lighthouse are, as of this writing, listed under Dangerous/Unknown.

Getting listed is free. A vendor emails vendor.relations@opendental.com. So when a company tells you listing is “in progress” or “not necessary for our architecture,” you are being told something real about their engineering choices, not about paperwork.

The Dentrix Ascend side has a harder gate. The Henry Schein One API Exchange lists 140+ authorized vendors, and authorization requires the vendor be SOC 2 Type II certified and use OAuth 2.0. That is a meaningful bar — it means an outside auditor has looked at their controls over a period of time, and it means nobody is storing your Ascend password in plaintext to log in as you.

Two ecosystems, two published lists. Neither one is hard to check before you sign.

The single question: “does the finished note land in the chart, or do I paste it?”

Ask it exactly like that. Then watch what happens to the room.

A tier (a) vendor answers in one sentence and shows you. A tier (b) vendor starts describing workflow philosophy — “our providers actually prefer reviewing in our interface,” “the copy is one click,” “we’re pushing native writeback in Q3.” All three of those are the same answer, and the answer is: you paste it.

When writeback is real, it also has specific properties worth asking about, because the details are where the honesty lives. On our own platform, the approved note writes into the Open Dental chart through the API, dated to the visit rather than to whenever the AI finished thinking. Attribution, though, is not identical across PMSes and no vendor should pretend it is: Dentrix Ascend files a note against a real provider field, while an Open Dental commlog has no provider field at all — so the provider’s name has to be written onto the body of the note itself. That’s a limitation of the data model, not a marketing choice, and any vendor claiming structured provider attribution on an Open Dental commlog is describing a field that doesn’t exist.

Same principle for corrections: signed notes should never be silently rewritten. Corrections file as dated addenda. If a vendor can quietly change a signed note after the fact, you have a records-integrity problem long before you have an AI problem.

What the honest answer sounds like

Nobody writes back everything. On Open Dental, our integration does not update appointment statuses, cancel appointments, or touch perio charts, and claims submission runs outside the PMS entirely. I’d rather put that in writing than let a practice discover it in week three.

That’s the tone to listen for. A vendor who names their gaps has mapped the API. A vendor whose integration “does everything” has usually mapped nothing, or is reading the database directly — which is how you can do everything, right up until you can’t.

Also worth knowing before anyone quotes you on “integration”: Open Dental sells its own eServices bundle at $165/month covering Web Forms, Patient Portal, eReminders, eConfirmations, Integrated Texting, Web Sched, Secure Email, and ODMobile. Open Dental has no first-party AI scribe — Bola AI is a native partner, not an Open Dental product. So the scribe conversation and the patient-communication conversation are separate line items, and you should price them that way.

Verify it in the demo — a checklist

Do this live, in a sandbox or a test patient. Never in a real chart.

Ask for the tier by name. “Are you on Open Dental’s Authorized list? Are you on the Henry Schein One API Exchange?” Then look both up yourself.
Make them dictate, approve, and then switch windows to the PMS. Refresh the chart in front of you. The note is there or it is not.
Check the date on the written note. Visit date or today’s date?
Ask where the provider’s name lands on each PMS you use.
Ask what happens to a signed note that needs a correction. Addendum, or overwrite?
Ask what audio and transcript are retained, and where. Our dictation path holds audio in memory only — never disk, never S3, never a database — and keeps transcript text for 24 hours so an interrupted or finished recording can be resumed. Separate, opt-in, consent-gated recording features are a different thing and do store audio. Any vendor giving you a flat product-wide “we never store audio” is either wrong or hasn’t read their own architecture.
Ask what else the same connection covers. One authorized API connection can carry intake forms and insurance card images, eligibility verification with writeback, payment posting, treatment plans, AR, patient search and create, and appointment reads and creates — the same rail, not five vendors. Five separate tier-(d) connections into one database is five times the breakage.

And confirm the BAA is signed before any patient data moves, not after go-live. That one isn’t a preference.