| Sometimes bad things happen to good people. | | | | equipment, configuration, line and power services, |
| Unfortunately, according to Murphy's Law, it will | | | | monitoring, etc. and then hire some very bright IT |
| also happen at the most inopportune time and at | | | | guy who would spend a lot of time to get this |
| a maximum cost. There really isn't much you can | | | | done. After it is all setup, the whole system |
| do to stop it. Bad things do happen – even to | | | | needs to be maintained and monitored. That's a |
| good people. What you can do is prepare for it. | | | | lot of life energy to spend on this problem. |
| Sometimes bad things happen on a geographic | | | | It is just not reasonable for a dentist to put these |
| scale. | | | | resources towards the problem of making a client |
| Consider the earthquakes in California a couple | | | | server based system sufficiently redundant to |
| years back. There were dental and medical | | | | accommodate even the most minor of disasters. |
| offices that were totally flattened. There was | | | | Does that mean that you just have to live with |
| nothing left to salvage in the practice – just | | | | the risk? If you are using a Client/server based |
| rubble. No charts, no chairs, no computer | | | | dental software system, the answer is "yes". You |
| systems. Whole offices were just flattened and | | | | just have to live with the risk. There are things |
| gone. Nothing to recover. | | | | you can do to help mitigate incrementally, but you |
| Hurricane Katrina resulted in a similar situation for | | | | cannot, for a reasonable price, craft a solution |
| the offices in New Orleans. Everything was | | | | that addresses the core issue. |
| destroyed – not just wet, but destroyed. The | | | | Consider a Web-Based alternative to dental |
| charts were totally unusable. The computer | | | | software. |
| systems were not salvageable and no data on | | | | With a Web-based system, you don't have a |
| them was retrievable. | | | | server in your office with patient data on it – |
| Sometimes the catastrophe will be more local. | | | | your data is located on the Web. No server to be |
| It is not uncommon for a burglary to greatly | | | | flattened in a collapsed building, no server to be |
| disrupt a dental or medical office routine. An office | | | | destroyed by a flood, no server to be stolen by |
| manager arrives in the morning to find the door | | | | an intruder, no server hardware to fail, no patient |
| broken open and the place a mess. Papers | | | | data to lose, no backup tapes to make or |
| scattered on the floor can be cleaned up fairly | | | | restore. You only have a very simple wire to the |
| easily, the stolen computer can also be replaced. | | | | internet. |
| But the information on it might very well be a | | | | If there is any event that makes your office |
| different story. | | | | computers inoperable, you simply find a new |
| Then there is the technical problem. Something | | | | computer with internet access. In the case of a |
| like a hard disc or controller card goes bad and | | | | geographic disaster, your office may be gone, but |
| scrambles all the data on your server. This type | | | | your patient clinical and billing information is intact |
| of problem can take hours or days just to | | | | and insurance collections can continue. In the case |
| diagnose. By then the cost of the hardware failure | | | | of a stolen computer you simply go to your |
| is 100 times as expensive as the part. Days of | | | | favorite computer store for a replacement and |
| lost production and wasted staff time add up | | | | plug it in. You are back up and running that fast |
| very quickly. It is not uncommon for a hardware | | | | (any other hardware failure, same story). Some |
| problem to cost an office several weeks, or even | | | | offices choose to have a spare computer on |
| months of clinic profits. Just what you want to do | | | | hand for just such a situation. |
| is work a month for free. It makes you worry | | | | Now, what about your data? Is it secure? With a |
| about the quality of your backup tapes. | | | | web-based solution, it's all kept in totally redundant |
| These examples are simply put forward to | | | | Network Operations Centers (NOC's) located in |
| demonstrate that things do break. It doesn't | | | | separate regions of the continent. All information |
| matter how expensive or what brand of | | | | is being stored simultaneously in both places and if, |
| computer hardware you purchase; it's not even | | | | for any reason, one of them is made inoperable |
| an issue of Mac vs. PC. Every piece of hardware | | | | (geographic disaster), the other picks up the slack |
| will eventually break. The question is not "if" but | | | | and you don't even miss a beat (or a byte |
| "when". If every piece of hardware will break at | | | | depending on your point of view). Hard drives and |
| some time, then doesn't it make sense to plan | | | | other computer components are expected to |
| for and expect it to break, instead of hope that it | | | | break. The system is designed to accommodate |
| won't? | | | | any piece or combination of hardware or |
| Preparation is the key. | | | | computer failure, and will still work. You don't even |
| Preparing for a disaster just makes sense. As the | | | | know there was an issue. |
| saying goes, "an ounce of prevention is worth a | | | | These redundant operations make the need for |
| pound of cure". | | | | restoring data from backups extremely rare. It is |
| Consider the prevention plan needed to | | | | not uncommon for a robust web-based system |
| accommodate for the potential computer theft or | | | | to never have the need to resort to backups. |
| computer component failure in a client/server | | | | However, in the unlikely event that a backup is |
| architected system. There are many points that | | | | needed, they are made every hour of every day |
| need to be addressed. You will need a second | | | | (and night). Nobody has to remember to make |
| server, equal in capacity and speed to the first. | | | | the backup and they don't need to be taken |
| Additionally, a separate power source should be | | | | home for "off-site" protection. They are |
| secured so that power to your building would not | | | | automatically backed up and electronically taken |
| be a single point of failure. Further, you need to | | | | off-site. Each backup is verified to ensure that it |
| have sophisticated software that manages storing | | | | will work if needed. |
| and retrieving duplicate data from two separate | | | | No dentist can build this type of infrastructure on |
| servers to ensure that if one fails, the other is | | | | their own. No client/server system can offer this |
| ready to take over. Also, those two servers | | | | type of redundancy and data protection. It's just |
| should be located in different physical locations, | | | | not feasible using a client/server technology. |
| sufficiently separated to ensure that a fire or | | | | Conclusion |
| earthquake or flood would not take both of them | | | | Bad things do happen to good dental offices. Client |
| out. | | | | server systems present risks that cannot be |
| In short, to prepare for uninterrupted service for | | | | reasonably addressed. Appropriately architected |
| a client/server system, a dentist would need to | | | | Web-based systems are inherently more secure |
| spend five to ten times as much money on | | | | and available than client/server based systems. |