Three Steps to Take if Your Technology Goes Down

July 12, 2011

When your EHR fails you, don't panic. Here's how to create the best possible 'downtime' plan.

Here are four words that no one likes to hear: "The system is down!"

They are usually followed by a string of four-letter words which, although temporarily cathartic, do very little to solve the problem.

To quickly define terms, a down system simply means that the software you rely on to manage your practice is not usable. This is particularly problematic for EHR practices that have successfully gone paperless. The EHR is amazingly convenient when it is working and amazingly inconvenient when it is not.

So what do you do?

Here are three foolproof steps to help you avoid panic when your system goes down:

Step one: identify the cause

The basic idea of step one is to isolate the problem enough so that you can go to Step two of the repair process.

A down system may be a function of hardware, software, the network, Internet access, or power loss. Who you call to get help is dependent on the causal factor. Your EHR vendor won't be able to help you if you are down because of an Internet issue.

For hardware, network, and software issues, you are probably not going to be able to identify the precise cause - but you should be able to narrow things down a bit with some quick and not-too-technical investigative work.

For instance, if you have your EHR installed on a server that is also supporting other office functions (e.g., e-mail) and you can use those functions but you can't log on to the EHR, you probably have an EHR software issue (as opposed to a server-based hardware issue).

If you are using a Web-based EHR, and all Web functions (including basic Web access) go dead, you have an ISP (Internet service provider) problem - not an EHR issue.

Step two: start the repair process

This usually involves calling the appropriate technical support staff, describing the issue to a technician, and allowing that technician to work their magic. The greater amount of relevant information that you have - for example, specific error messages, the circumstances under which the system stopped working, recent changes to hardware or software - the easier it will be for technicians to assist. Although a down system is stressful, stay calm and focus on the facts.

There are times when isolating the problem is not obvious, especially when trying to differentiate between hardware/network and software issues. Example: The EHR has slowed to an unusable crawl and all other server/network applications work fine. While it might seem like a software problem, this could easily be a network or server factor.

In these cases, you may need to place calls to your hardware/network and EHR technical staff (they are almost always separate groups) and describe the issue to both. If each group is stumped or if they instinctively declare it is the other guy's issue (a common occurrence on tough, non-obvious problems), you will want to set up a conference call with both parties on the line to discuss proposed solutions as a unified team. This will help you avoid ping ponging between the hardware and software tech support groups and will expedite a fix.

The good news: Any reputable support organization is going to prioritize calls in which the system is down, so you should get a reasonably quick response - usually within 30 minutes. And ideally, the experts will be able to come up with a quick fix. However, in the meantime, you will need to trigger your system downtime plan.

Step three: initiate system downtime plan

Your downtime plan defines how you will continue your clinical and business operations in the event that you can't utilize your computer system.

For clinical operations, it means you will be temporarily using paper and/or transcription to record patient visits and paper super-bills to capture charges. No electronic scripts: When the system is down you will be temporarily back to the paper prescription pad (which means that you may want to have spare pads/paper documentation tools around just in case). As part of the plan, you will also want to ensure that paper documentation collected during the downtime is entered into the system once it is back up and running.

In addition to downtime documentation, a practice needs to consider methods of making patient histories available during the downtime. For practices still in transition between paper and electronic systems, paper charts will probably be fairly accessible.

For practices in which paper charts are not easily accessible, there are technical solutions that can help. The use of an uninterrupted power supply (or a "UPS") as a temporary battery would power your primary server and printer and allow you to print out schedules and patient summaries in the event of power loss.

Isolating an individual PC with a copy of the EHR software and patient database would provide a single workstation backup in the event of the software/network meltdown. Consult with your EHR and hardware experts to come up with plan that is practical for your practice.

To keep the practice running as smoothly as possible during downtime, it's important to define and communicate your downtime plan to staff in advance of problems so they know what to expect and how to respond.

Any downtime plan has to include a strategy for backups. Data backups are your insurance in the event that you suffer an issue that destroys or corrupts your patient data. If a catastrophic data issue occurs, you will need to "restore from backup," which simply means that the corrupted data is replaced by the latest backup. If the latest backup is a week ago, you will have lost a week's work of data (hence the need for daily backups).

There are multiple techniques for managing backups (a topic for another column). The key issue is that you select a daily, reliable, and predictable approach you can count on in the event that the worst case actually occurs.

Bruce Kleaveland is an industry veteran and healthcare IT consultant based in Seattle. He can be reached at bruce@kleavelandconsulting.com.

This article originally appeared online in the July/August 2011 issue of Physicians Practice.