tim wrote:1. We would like to streamline the installation of our plugin for users. Would it bad practice to automatically insert an entry into the program table during installation of our application?
It would be bad practice due to potential compatibility purposes when your customers update versions of Open Dental. There are many things that could go wrong. E.g. We could have changed the schema of the table / how the table interacts with the software.
It is best practice to use our methods to manage any Open Dental tables within the database (not owned by your plugin).
With all of that being said, this is a great question because there currently isn't an alternative solution to manually manipulating the database. In order to correctly call our methods to manipulate the database, your plugin had to be activated on application startup (which doesn't happen until the user manually adds the Program Link).
I'll suggest to my CEO that Open Dental should do some development for initializing plugins and automatically creating corresponding program links. We could even notify the user that a new plugin was detected and ask them if they want to enable it / visit the Setup window for it (in case additional setup is desired).
The only other thing I can think of would be for you to include the OpenDentBusiness.dll within your installer application and make a connection to the Open Dental database and then invoke our methods to add the necessary things to the database. This of course would need to be versioned which means you'll have to keep up with our release cycle which doesn't sound like a good solution to me (if I were you).
tim wrote:2. We have a Windows service that performs various synchronisation jobs with a remote HTTP server (i.e. the sync happens outside of the OD plugin). The results of these syncing jobs will require inserting/updating/deleting records in the OD database.
- 1. Is it acceptable to perform database updates outside of OD?
2. (If applicable) How should DB credentials be shared between OD and some other application on the machine (e.g. read a file in a well-know location)?
2 - 1. Much like my answer for #1, you should not manually manipulate any Open Dental tables. It is fine to manipulate any custom tables created by your plugin.
Some alternative solutions could be:
- A custom table that flags FKs of other tables and then your plugin could either add/remove these objects from/to the database utilizing our methods OR you could go as far as to completely take over necessary controls in the program in order to "hide" or "add" these synchronized objects into the UI.
- Use our HL7 or FHIR paradigms which are currently being used for these exact purposes but are very "lite" at the moment. Open Dental would need to agree upon a paradigm for each "object" that you need to manipulate and provide you with a structured way of telling us what needs to be done (I suggest sending detailed information to
vendor.relations@opendental.com).
http://www.opendental.com/manual/hl7.html
http://www.opendental.com/manual/fhir.html
2 - 2. I don't think sharing credentials is a good idea. You could have your users give you the credentials necessary when installing your applications and take care of them however you see fit. If Open Dental was to in fact "share" credentials with you, it would be more along the lines of an OAuth paradigm (that would take programming time).
tim wrote:3. Is it possible to programmatically import documents into the Images module? (If applicable) Does this depend on the document storage method that the practice is using (e.g. A-Z folder vs. storing directly in DB)?
It is possible and you are probably interested in looking at the code found in ContrImages.ToolBarImport_Click(). The most interesting part for you will be ImageStore.Import(). Yes, it heavily depends on the document storage method that the practice is currently using.
FYI - There is already a plugin hook call that you can tinker with at the beginning of the ToolBarImport_Click().
tim wrote:4. There is external data we would like to display about a patient in the chart module. This data should be fetched on demand using the current patient context (i.e. not stored in a table and periodically refreshed by some background service). It seems like this information would fit into the progress notes section, as the data is a kind of lab case. Is it possible for a plugin to display dynamic data in the progress notes view? Or, is the preferred way to do something like this to just add a plugin button to the chart module and display the results in the new window?
There is not a built-in way that Open Dental gives 3rd party plugins to incorporate displaying any sort of data to the user.
However, with plugins, you can do anything you desire to the UI of the program. You could take over the progress note grid and tack your dynamic data anywhere you want. You could add an entirely new grid that is docked somewhere in the chart module that always changes with the patient. Or, like you mentioned, have the user click a button to get at such information when they need it (least amount of programming time).