Multiple Locations 

Open Dental is useful for multiple location scenarios as described below. Also see the Remote Access page for information on accessing data from outside your office.

Separate Databases
This is the simplest approach for true multiple locations. Each location has its own local server and unique database. This works very well for most situations. There are some disadvantages.  You can't see all patients from all offices at once, although we have a planned feature which might be able to handle this some day.  There is also no centralization of data.  There are tools available which can coalesce data from multiple databases, but it would be up to you to find and select the tool to use for this purpose.  Moving patients between offices is the last current disadvantage.  Patient transfer is a planned feature, but it will be a long time.

Terminal Services
We have many offices using Terminal Services (TS) successfully. Open Dental is specifically designed to run well in this environment. This is currently the preferred solution for multiple locations. First, set up a VPN so that data moving across the network is secure. You would have one centralized server, and use TS at all computers that were not at the central office. You will have a mixed environment, with some or all computers at the central office still connecting to the database using the standard server client method. The reason for this is that it will decrease the load on the server. Also, the computer that you use to send e-claims should be a standard workstation rather than a terminal. One disadvantage of TS is that it does not scale up very well for more than a few locations. Some other disadvantages are that terminals cannot be used for digital radiography and transfer of large image files is slow.  The 3-D tooth chart does not work on TS, but there is an option to use a simple tooth chart that does work over TS. If you are using TS, you should change the following options:
Module Setup: Appointment module bubble popups, disable.
Graphics: Use Simple Tooth Chart.
Both of these options reduce the graphic intensiveness of the application.

VPN
Most of the solutions below start with the establishment of a Virtual Private Network (VPN). Each location would be connected to the internet by a broadband connection. Options include cable, DSL, T1, or possibly wireless. There are different types of VPN solutions and a network specialist would have to set it up for you. It typically involves a special router or some software. Once the VPN is set up, the offices should be securely connected and function as if they were a single office.

Direct Connection
You could connect directly to your central database using a fast VPN. But Open Dental can make up to 20 calls to the database on some screens, and this delay is noticeable. Some internet connections are getting fast enough to allow this sort of direct connection, but it's something that simply has to be tested to know if the speed is going to be acceptable.  Even in the speed is annoyingly slow, it can still be a temporary solution.

Multiple Databases on One Server
If you have multiple clinics, and you find the speed of your direct connections acceptable, you could put multiple databases on a central server.  This solution could work very well.  It has the big advantage of not requiring you to merge the multiple databases into one.  Merged databases are very difficult to later split if circumstances change.  Also, by having all databases on one server, it is easier to run reports on multiple databases at the same time.  The reports would not be included with Open Dental.  They would be custom SQL queries which would pull data from multiple databases.  It would be best to have someone on your staff who was expert enough in SQL to be responsible for writing and maintaining such queries.

Notebook Computer
If you have two locations, but only access data from one location at a time, then you could use a notebook computer as your server. Just take it with you from location to location. There can be other workstations that use the same data, but they will not work until the notebook returns and is connected to the local network.

External Hard Drive
If you have two locations, but only access data from one location at a time, then you could physically take the database with you. You would set up two separate servers, one at each location. And on each server, MySQL would only be functional if your external hard drive or USB flash drive was plugged in. But it's tricky. Your database would be on the E: drive or something similar. You would have to know how to use our installer to install MySQL to run the database from the alternate drive. You would have to know how to then move your database to the new location. You would have to shut your server down each day before removing the hard drive. And then when you start your server back up, you would have to become very familiar with knowing how to start the mysql service if it wasn't already running. This is not a good strategy to take data home at night for three reasons. First of all, it interferes with the proper Backup strategy, which is to make a copy of the data and run it at home. Second, until you bring the hard drive back to the office, nobody can work. Lastly, it's too complicated for most users.

Daisy Chain Replication
Daisy Chain Replication is a way of having multiple physical servers but only one virtual server. The servers at each location have identical data and they stay in synch using MySQL replication.  This works fairly well for less than 10 servers, but will become cumbersome as it scales up beyond that. There is a weak link problem, where if one link in the chain is broken, replication stops for everyone. You would need to have a resilient recovery protocol if a database at one location becomes corrupted or if replication fails. We have a few offices successfully using this strategy.

Vertical Application Partitioning
This is NOT yet a feature of Open Dental. As with all Future Versions, we cannot make any promises about when or if this feature will be added. This document describes vertical application partitioning: MySQL Scale-Out.  The partitioning strategy is fairly straightforward.  It would be done by clinic.  Each patient may have a ClinicNum indicating the clinic that has "owns" the patient data.  Other patients would be available for read-only uses. As the paper points out, a synchronization mechanism must be established between the partitions (they refer to it as an "asynchronous inter MySQL replication cluster").  This is the complicated part.  For our purposes, a delay of up to one day might be acceptable. The specific synchronization mechanism has not been worked out yet and continues to be a topic of much discussion.

3-Tier Architecture
We previously put considerable effort into a 3-Tier Architecture with a Server Component to address the slowness of a direct remote connection. But the server component is rough around the edges, and does not currently increase speed. We have also temporarily halted progress on this 3-Tier Architecture in order to pursue the web version of Open Dental instead. 

Clustering
One database can be spread across multiple physical servers.  This is not a way to have one database at multiple locations.  Instead, it's a way to increase the speed and reliability of a database at one location.  But if you are heavily loading your database by using Terminal Services at multiple locations, then this might become necessary to increase the power of your central database.

Web Version
See Web Version