Curbside Consult with Dr. Jayne 8/17/15

Dr. Jayne Does Downtime

Although I have a steady urgent care gig, I occasionally cover locum tenens assignments. It’s a great way to be able to use multiple EHR systems so I can see what vendors are doing for Meaningful Use and overall EHR usability.

I knew I was in trouble this week when I arrived at my assignment to find the EHR down. It’s a small practice with multiple locations and they have contracted IT support, which the staff had already called. With little chance of the system being up before patients arrived, we decided to activate the downtime procedures.

I was initially impressed. The staff knew where to find the downtime documents on the shared drive and started printing them out. They began to put packets together for each scheduled patient and started digging out a pile of clipboards. The front desk team pulled out an old-school credit card imprint machine and readied a cash log. Staff started rooming patients.

As I saw my first patient, I realized they had no way of accessing a patient summary. There was no local downtime solution. I couldn’t even get a medication list or problem list on the patients. Staff was asking them to summarize their histories, which was going to take a long time based on the number of geriatric patients on the schedule.

As I flipped through the downtime packet, I realized there wasn’t a SOAP template for the physicians to write their notes. There was a page that said “Findings” and “Plan,” but that was it. It had huge ruled lines on it that weren’t very practical for writing a patient care note. I divided it into virtual quadrants and started figuring out my own note format, while sending out a text to a physician working at one of the other locations asking for advice. All the locations were down so I figured he’d be in the same boat and may have a better idea.

I realized that the “Findings” sheet didn’t have a patient name or date of birth on it. The staff had written that vital information on the top sheet of the packet only – the sheet which was the directions for how to use the downtime packet, and had nothing to do with the care of the patient. I scribbled on the patient’s two identifiers to at least preserve the integrity of my notes and hurried to the next patient.

She wasn’t quite ready to be seen, so I waited for the medical assistant to come out of the room and asked for a quick summary. The medical assistant was beyond agitated. Apparently the idea of working without a chart and not knowing anything about her patient was making her anxious. I looked at the size of the medication list she had jotted down and empathized, knowing that they’d have to backload a significant amount of data once the system came back up. She didn’t respond well to my reassurance and looked like a deer in the headlights. I told her to take a minute and gather herself and let her know we’d make it through the day.

Minutes turned into hours, and before I knew it, we had been down half the day. A new kind of anxiety emerged as the staff realized they would have to have the data loaded into the system before they left for the night. I asked if they really needed to load all the data or if there was an identified subset of information to load. Unfortunately they had been told that they had to load everything that had been documented on paper. Several were worried about being able to get out of the office on time to pick up children and keep other family and personal commitments.

In my past life as a CMIO, we had a subset of “Core Clinical Data” that had to be loaded after a system outage. It was the vital information that would be useful in ongoing encounters, such as medications, allergies, diagnoses, problem list, immunizations, lab orders, charges, and plan details. The physicians could also identify other key data or particular exam findings to be loaded on top of the core data, but the expectation was not that every single scrap of data would be loaded. Practices had 24 hours to get the data loaded rather than trying to get it done by the end of the workday. We had experienced more than our share of downtimes and it worked well for us without a lot of extra overtime or anxiety.

The system came up shortly after lunch. We were excited and ready to catch up, only for the system to go down again after about 30 minutes. We continued plugging away, but it was frustrating because we weren’t getting any updates from the IT support team or from the vendor. I asked the staff what the expectations were and no one seemed to know. I suggested someone pick up the phone and ask what the schedule was for expected updates so that they would feel less in the dark. It hadn’t really occurred to them to do that.

As we got closer to closing time, I asked about any plans to cancel patients for the following day. It turns out we didn’t have the option since they only print patient schedules one day in advance. We had no idea who would be on the following day’s schedule or how to reach them.

The system came up for good during the last scheduled patient appointment of the day. We got the office administrator to agree to letting the backload process extend into the following day. The staff relaxed considerably and we were able to get about 30 percent of the charts loaded before they had to start heading home for the night.

There is a fine line between a smooth and polished downtime and complete chaos, but the steps to keep it closer to the former are pretty straightforward. My advice of “must have” elements:

• Practices need a solution to obtain at least a brief history on existing patients without asking the patient to provide it. This can take the form of a daily download of patient summaries to a local server and at a minimum should include the patients scheduled for the next work day. Ideally one would want a download on all active patients in the practice.
• Practices need to actually practice for downtime. Especially if you’re in a situation with a stable system and it never happens, staff needs to be aware of the policies and procedures and be ready to deploy them when needed. Surprise downtime drills every month aren’t a bad idea and it doesn’t have to be a “live” drill – it could be a tabletop exercise at a staff meeting where everyone talks through what they need to do in the event of a system outage.
• Identify the core data that needs to be loaded once the system is up. Don’t sweat the small stuff if it’s already documented on paper and scanned. Be sure to reference it, however, so that users looking at the chart in the future will be aware of the presence of additional details should they be needed. Any paper forms that are to be used should be clear and concise, with review and approval from the teams that have to use them.
• Make sure you understand the service level agreements with your IT support staff and with your vendor. Don’t expect hourly updates if they’re not obligated to provide them or you haven’t asked for them. If you feel like you’re not getting the information you need, speak up.
• If you don’t have a local copy of the system that shows at least several days’ worth of appointments, print at least several days’ worth of schedules in advance or save them to a local drive. It’s a few extra steps, but well worth it to not be surprised when people show up at your reception desk.

By the time I was cleared to leave I was exhausted, so I can only imagine how everyone else felt. I headed back to my hotel and picked up some take-out on the way so I could get into bed early. Even if the EHR is completely cooperative, it’s going to be a long day.

How do you handle a system outage? Email me.

Email Dr. Jayne.