If you are an ASP client and you are considering the purchase of a local eClinicalWorks server for your practice, you owe it to yourself and your patients to read this.
The potential for lost revenue, extended downtime, and unhappy patients is significantly greater for customers with local servers. Before deciding on a local server, think carefully about the following points.
Installing a local eClinicalWorks server can sometimes resolve occasional day-to-day frustrations, but it creates new and far greater problems. A local server is just one computer. If it “crashes” catastrophically or is stolen, your practice will be down for days or weeks, even if you buy a premium warranty with a vendor-advertised “4-hour response” (see the long version below for the explanation). Local servers rarely enjoy reliable backups because such systems require diligent attention and maintenance. Without bullet-proof backups, your practice could suffer disastrous consequences. In the case of theft, your patient data will be in unknown hands, leaving your practice liable for multiple PHI exposures, each carrying federal penalties. The long-term benefits of ASP technology outweigh any transient issues, while the risks of using a local server overshadow any advantages. It is in your best interests to find out more about our ASP service.
1. Server Crashes
If your server crashes due to a failed hard drive controller, disk array, motherboard, or what have you, then you must place a service call to your vendor or IT consultant. The best warranty available for local servers (from Dell or IBM, for example) provides on-site service within 4 hours, for which you pay a premium price. Here’s what they don’t tell you. If your disk array is corrupted by a hardware failure, the repair technician’s job is to replace the faulty part(s), leaving you with a perfectly functional—but completely blank—hard drive. The Dell or IBM technician is not responsible for bringing your server back to fully operational status, as that involves reinstalling and reconfiguring the Windows operating system and eClinicalWorks software, and then restoring your eClinicalWorks data (assuming you have reliable backups—see the section on Backup Procedures). Practices that experience such failures are typically down for days or weeks, even if they have a “4-Hour response” warranty.
If you install eClinicalWorks on a local server, you must establish a bullet-proof backup methodology. This is harder than you may think. Many things can go wrong with automatic nightly backups. Your backup report may indicate that certain files were skipped, but the backup software does not know if those files are critical to your eClinicalWorks system. It cannot detect data corruption, so it does not distinguish between corrupted data and good data. Hence your report may indicate that a backup completed successfully when it did not. Your in-house staff does not usually know how to interpret or respond to these events either—even if they are IT savvy. Too often, practice managers have faithfully changed their server’s tapes every morning, not realizing that their system stopped backing up properly months earlier. Incorrect media management, worn tapes, malfunctioning USB devices, magnetic interference, human error, and so on, can lead to situations where your most recent good backup is days, weeks, or even months old.
When the employee responsible for handling the daily backups leaves your practice, they typically do not fully explain their backup responsibilities and procedures to their replacement. Thus, employee turnover leaves your practice with a false sense of security and without good backups.
If any of the above happens, could your staff fully rebuild days’ worth of encounters from memory, not to mention scanned images, referrals, reports, correspondence, and faxes that must be recaptured?
Reliable off-site backups are difficult to accomplish. Once such procedures are established, they typically break down. The weak link is the human responsible for transporting the backup device(s). Also, transporting a data tape or USB drive containing patient health information (PHI) is considered to be a “data transmission” under HIPAA, and must be done in a compliant fashion.
Internet-based backup systems do not usually work for eClinicalWorks. If you are considering such a solution, ask the backup company to fully explain how their system handles “open MySQL databases.” Speak to a technician, not to a salesperson. Most off-site backup solutions do not properly handle eCW data—i.e., your scanned images get backed up but your database does not. Even if the off-site company can properly backup the eCW database, consider what happens if your system crashes and you need to request your data back. Since your data has been accumulating for months or years, to download it through the Internet would take many hours or even days. Alternatively, the off-site service may ship your data overnight on a USB drive, in which case your downtime might be limited only to the time it takes to obtain a new server and rebuild it (see the section on Server Crashes).
If you arrive for work one morning and discover that your office has been burglarized and you server stolen, your practice will be down for days or weeks while you obtain, install, and configure new hardware, and then arrange for a certified eClinicalWorks installer to install and configure your eClinicalWorks system. Even then, success relies on whether you have reliable backups (see the section on Backup Procedures).
Worst of all, this nightmare scenario involves thousands of stolen patient records that are now in unknown hands. Each patient exposure represents a HIPAA violation carrying a fine of up to $100,000 per case.
How safe is your area against the threats of fire, flood, earthquake, tornado, hurricane, electrical outages, and so on? Our data center is located in one of the only disaster-free zones in the United States, which is why the federal government has sought (unsuccessfully) for decades to establish a nuclear waste repository near Las Vegas.
HIPAA requirements are becoming stricter, not more relaxed. Complaints and investigations are on the rise as patients become more aware of their rights and their healthcare provider’s responsibilities under law. Would an eClinicalWorks server sitting somewhere in your office be HIPAA complaint? Most anti-virus solutions do not catch many kinds of viruses, worms, and “back door” programs. Users frequently install them without even realizing it. Chances are good that your server would not be secure against remote access by intruders or against the more mundane threat of simple theft. In that event, your patients’ records would be in unknown hands, leading to PHI exposures, each case carrying severe federal penalties.
Your ASP servers are continually maintained, upgraded, monitored, and analyzed by eClinicalWorks-certified professionals to (1) ensure optimal functionality, and (2) anticipate and avoid problems before they occur. That same level of attention to your local server is possible but would be expensive in terms of a consultant’s time. Also, consultants that fully understand the inner workings of eClinicalWorks are hard to come by.
For these reasons and others that we haven’t explored, it is in the long-term best interests of your practice and your patients to go with an ASP service rather than a local server.
Choosing an ASP solution will prevent so much of the added hidden costs that will create major issues for your practice. Let technical experts with technical environments handle your technology, while you focus on providing the best care for your patients.
What if your particular issues are not resolvable? In that unlikely case, we would strongly advise you to weigh the potential loss from extended downtime or theft of patient records against the occasional day-to-day frustrations of accessing eClinicalWorks over the Internet. You may find that benefits of using an ASP service still outweigh any disadvantages.