Open Dental Forum

I know there are a lot of available API options for Open Dental and I've done my best to find the documentation talking about all of these, but I am still missing some pieces and would like some clarification.

Read Access Options

• Plugin
• Direct Database Connection
• Open Dental API

Read / Write Access Options

• Plugin
• Open Dental API

I understand there's another API whose use is discouraged, called the FHIR API, that I'm leaving out, since we're not considering it an option.

One question I have is regarding a brief chat I had with some other developers in one of our sister companies that has also done Open Dental integration. They told me they are using a direct object API integration, like an SDK, where they use Open Dental classes for both reading and writing to the database and that it covers, in their words, virtually everything. The question I have for that is, does that mean they're using a plugin they wrote or is there another integration point I'm missing? And, if it is a plugin, do plugins always have to be either embedded in the Open Dental UI or triggered from an action in the UI? Or can we have a console application that, for example, runs on a schedule that integrates with Open Dental through the plugins support?

I'm really not sure. They might be using a plugin of some sort, but I've never heard of that approach. As we move away from plugins and toward API, I would not expect that approach to be future proof. We will likely add some security to prevent that sort of end run. If they just call random methods that are in our business layer, they are bypassing all the security log entries, just as one example. Plugins are good for adding a new window in Open Dental, but they're not supposed to be used as you describe.

OK, that's good to know. And to be clear, they didn't say they were using a plugin from, for instance, a console application, only that they were able to access the database through objects within Open Dental. I assume that's normal when you're writing a plugin, right? If what I'm asking about sounds unusual then I would assume it's not the way they're doing it, again I am just trying to find out what's possible and beyond a few sentences for how they interact with Open Dental I don't have any details on how it was done.

I didn't know the plugin framework was going away, is that what you're saying? That a plugin we write today may not work in the future? Or are you only saying that if we were circumventing intended use cases of plugins that that might not work in the future?

We've had a warning posted for a year and a half that we are about to start blocking plugins and external queries from making changes to the database:
https://www.opendental.com/manual/plugins.html
The reason we've been holding off is that we obviously have to have the API mature enough to be a viable alternative. We will, without a doubt, block third parties from writing to the database using plugins before too much longer.

OK, that makes sense to me and I have read that article you linked a couple of times, but I don't remember it saying that the plugin framework is being removed. To be clear though, that is what is happening, right? They will no longer be supported and existing plugins are going to be blocked, requiring the makers of that software to write a new solution using the API in the future?

On that page you linked, this is what I understand it to be saying regarding plugins (which sounds like something different than what you're saying so I just want to clarify)

• That they should not be used to modify the database (unless it's a table you've created and maintain on your own)
• That instead you should use the API if you need to modify the database
• That direct writes to the database or writes through plugins will start to trigger a warning in the future

Thanks again for all of your help Jordan, this is good information that will help us a lot.

If you make changes to the database directly (not with a plugin), starting in version 21.5, that will trigger warnings to the users which could become quite annoying and insistent over time. As a completely separate issue, plugins that make changes to the database are different. There is no technical way to block plugins from making changes to the database, so we need to resort to vetting plugins. Unvetted plugins will be blocked, also starting in version 21.5. The vetting will probably include a grace period for existing plugins, but no plugin will work in 21.5 unless we have been in communication with the developer.

When you say "make changes to the database" are you just talking about UPDATE and INSERT commands or are you also talking about schema changes like creating new tables?

Update, Insert, etc. Any change like to one of the tables that we will start tracking. Examples might be paysplit, patient, and appointment. Anyone is always free to add their own tables.

OK, awesome, and for the plugins, again, no changing of the database data either directly or indirectly through libraries / classes that exist in Open Dental itself, right?

Will the plugin framework continue to be supported for those who just want to use it for read access?

Hello. Trying to integrate Rhinogram to Open Dental. They are saying the API code has to be integrated but Open Dental is limited to knowing how to do this. Please advise on how to integrate with an API.

Thanks
Candice

Right, plugins should not change the database either directly or indirectly. Plugins also aren't a good tool for read access because you can instead just use queries.
For Rhinogram, that company would be the one to write the integration, not Open Dental. We provide the API, and they use it.