Open Dental Database Goes Mobile

[brandonj]

Hello all. I have a couple scenarios for you fine folks to consider.

In both scenarios Dr Joe has a dental clinic. Dr Joe would like to occasionally do mobile dentistry on camels in the Sahara desert where no internet access exists. Some of Dr Joe's staff will remain at the clinic while he's abroad to do various scheduling and billing tasks.

Scenario A - Dr Joe takes a copy of the Open Dental database with him on his laptop. He does lots of top notch dentistry and updates Open Dental on his laptop accordingly. Meanwhile, the staff is back at the clinic furiously scheduling new patients and posting insurance payments on the clinic database. When Dr Joe returns, is there an easy way to merge the two (now different) databases into one again so that both his work, and the work of his staff, is preservered? How would this be accomplished?

If Scenario A isn't possible then:

Scenario B - Dr Joe takes a copy of the database with him on the laptop.
Same as before. This time, Dr Joe has some way of locking the database at his clinic so that his staff can have read-only access to the data.
They cannot (even mistakenly) make any changes to the clinic database while Dr Joe is gone. However, the staff can at least see the clinic database and write down changes they need to make when Dr Joe is finished globetrotting. When Dr Joe does finally return, he overwrites the clinic database with the database on his laptop. The poor staff members can then work through the night updating the clinic database with all the changes they have written down on dozens of legal pads.
Is there a mechanism to accomplish this?

Thanks in advance for all of your helpful replies!

Brandon

P.S. I realize Open Dental was not designed for dentistry on camels.
Let's just assume Dr Joe has worked out this minor detail. Or let's assume that he really doesn't ride camels in the Sahara but rather drives to the north part of the county for the day to serve a remote population.

[KevinRossen]

My initial thoughts are that scenario A is possible with a few caveats. The biggest problem I can see has to do with Primary Keys in the procedurelog. I'm by no means an expert on how the database is structured, but I do understand that EVERY procedure gets a unique key, which I assume goes in numeric order as they are added to the database.

So, if you setup all the appointments/procedures you're going to be doing ahead of time before riding off on your camel, then I think it's possible. It would take building a few queries that would take the updated data from your mobile database that would then update the main database. But I really don't have a good idea on how you would make that happen realistically.

If these mobile patients aren't part of your local clinic, maybe you could see about setting up a standalone database as a mobile clinic?

[teethdood]

I agree with Kevin. I would consider a different database for the Sahara patients.

Now if you still want to do scenario A or B.

Scenario A: you're going to pay the OD team $300 each time you want to merge the two databases
Scenario B1: just copy the database in c:\mysql to your laptop for your Sahara trip, then when you're back in civilization simply overwrite it with your laptop's c:\mysql
Scenario B2: create a virtual server for your office, then copy the virtual server over to your laptop, then transfer the virtual server back to your office when done. Of course with this method you'd be running 2 instances of windows which is technically illegal if you boot them up simultaneously.

It's V-Day and both my wife and I are glued to the computer...hmm

[Ryan]

I apologize for using the "R" word, but Open Dental can do all of that by using "Replication".

Replication is a powerful technology built into MySQL. Open dental supports this replication through the use of key-ranges and random primary keys. Details can be found in the online manual here: http://opendental.com/manual/replication.html. BEWARE: Switching to random primary keys is irreversible.

In short, OD is designed to use replication for exactly the type of situation you are describing. For instance, if a clinic wanted to use five or six (or more) mobile dentistry vans to go out into the world and spread good health. They could all operate independently and then, when all the work is done, connect to the main office and update all the databases so they all contained the same information. If you are interested in implementing replication you must get VERY familiar with the way your network is setup and how you are going to use replication. Read all the documentation before starting. Then, if the time comes, test your replication in a test environment before throwing your production database into it.

Having said all that, we have plenty of happy customers that are currently using replication and would probably be willing to share their thoughts, insights, and opinions. Just fire up a new conversation thread about replication and mobile offices.

Happy Hunting
-Ryan

[KevinRossen]

So, what you're saying is Open Dental can do anything, right?

[Justin Shafer]

lol, I kept thinking why don't we just use the internet on mobile?

"Dr Joe would like to occasionally do mobile dentistry on camels in the Sahara desert where no internet access exists."

Sweet!

Someone told me about replication and packet loss being a problem for multiple offices? Is that why we should test our network first?

[Ryan]

Yes, Open dental can do ANYTHING*!

Packet loss can be a problem in any network, but it can hit a replication network pretty hard. If you are going to "go mobile" and only connect with your main server when you get back to the office then this shouldn't be a big problem for you since the satellite computer would only try to replicate when it is firmly connected to your home network. If you were trying to keep a live connection open to the master server the entire time you were away the opportunity for errors would increase.

Testing is important because there is such a wide variety of problems and issues that may occur - network connections, packet loss, bandwidth, latency, firewalls, ISPs, Hardware nuances, connection limits, Replication settings in Open Dental, replication settings in MySQL, the sun, the moon, and the stars - the standard gambit of IT problems. Think of switching to replication like switching to a new software, you wouldn't want to switch to Open Dental without testing it out first (Or maybe you would?!). Similarly, you wouldn't want to switch to Open Dental with replication, without testing it out first.

*(some restrictions may apply)