Multi-tenant Hosting

One data center might want to host databases for multiple Open Dental customers. These databases may be on the same physical machine if care is taken to isolate the customers from having access to each other's data. With Open Dental, it may be more accurate to refer to this as multi-instance rather than multi-tenant since different customers will never share the same database.

Also see: Multiple Location Options

Virtual Machine

The current recommendation is for each customer to have a separate virtual machine (VM) with its own instance of MySQL and its own A to Z folders. There can be some economies of scale compared to a traditional server because multiple customers can share the same hardware. There are also some advantages in disaster recovery because a VM can be easily moved to a different physical server.

Connection Security

When clients connect to the server over the internet, the data must be encrypted. The current recommendation is for the VM to be connected to the physical office by VPN. There might be other options that we will list here in the future as we become aware of them.

Workstation Connections

The three workstation connection options are direct, RDP, or Middle Tier. This still applies to multi-tenant scenarios, so the workstation connections must be considered as part of the complete solution.

Multiple Databases on One Server

This can only be done with Version 12.4 or later.

Store Images in Db: We recommend switching to Storing Images in Database instead of in the A to Z folders / OpenDentImages. This is not strictly required, but prevents an obvious security problem. If A to Z folders are used, they must be shared with everyone. Storing images in the database eliminates this requirement and the complexity of managing those folders and permissions. Carefully review the features that are not supported in that mode.

MySQL Security

A different MySQL User will need to be set up for each customer (MySQL Security). If, for example, a customer database is called od_springfield_4932, then you must set up the MySQL user for that customer to have full access to od_springfield_4932*. Notice the * wild card character. This allows Open Dental to make backups of the database during the update process. The MySQL user must also have full privileges, including create table and drop table.

You may want to work from particular devices or IP address ranges. Information about setting up usernames for specific devices or network segments is available on the MySQL website: http://dev.mysql.com/doc/refman/5.5/en/account-names.html. Open Dental does not provide advice or direct support on setting up usernames for particular devices or network segments. We recommend contacting an IT professional. Open Dental is functional as long as the specified MySQL user has the correct (full) permission set.

HL7 Service

For example, if the customers are bridging to eCW using HL7 (eClinicalWorks HL7), multiple instances of the HL7 service will need to be set up, each with a different service name, exe folder, FreeDentalConfig.xml file, and database connection. Different customers may be on different versions of Open Dental. Each HL7 service can be shut down independently as needed.

Prior to Version 12.4, the OD HL7 service could not run multiple instances, nor could it support multiple customers. In spite of this known limitation, some data centers attempted to set up multiple customers on a single server. In every single case, the HL7 folders were set up without enough attention to detail, and data between different customers was repeatedly mingled and databases were repeatedly corrupted. This was obviously completely unacceptable, and this was our main objection to using a single server.

HL7 TCP/IP

We recommend HL7 TCP/IP ports instead of HL7 folders. This will eliminate any HL7 folder sharing issues (Generic HL7).