“What if you put MicroSoft Word, PowerPoint, Excel, Outlook, Internet Explorer and the FireFox browser in your Windows Start Up folder?” Every time you signed on to the PC, it would take minutes to load everything, when you often only needed one application or at least one application at a time. That could be the impact of using a single, all encompassing and exhaustive data retrieval view as a default view in an EMR. In the land of today's EMRs, that might be between 10 and 30 seconds per screen flip. Not the 10 minutes of a Windows start up, but you get the point.
Response time performance comes at or near the top of the list of physician issues, across vendors ... unless...
Unless the EMR system has support for workflows that recognize the user's intentions. Intentions like "what do I need to see first in this care setting?" For example, in an ICU, a physician often first needs to know the patient's current vital signs, long before they want to review their patient's current orders. Or, "I'm just here to sign my charts," or "I just want to see results that I haven't yet seen, to make sure it's reasonably safe to leave the hospital and go home at 9 pm when I'd hoped to be home at 6 pm."
Every modern EMR I've seen from all major vendors as well as the VA and homegrown systems have support for multiple, different workflows. The good news is that the resulting screen flip times are usually fast and the physician satisfaction is high. The
bad news is the training issue.
Most hospitals and vendors have been forced by important users into building the exhaustive view described above. When that view is the only one that's rolled out and taught, the outcome is variable dissatisfaction. For infrequent users and patient's with short stays, the performance hit per physician can be relatively low. It's a time bomb though. It either goes off at go-live, or in my experience, months or years later ... somewhat predictably.
Either the user needs to know that the "fast and easy workflow" feature or screen is there, either by default or one click away, or their IT department needs to know and build that into the user's experience (which includes training and product implementation build ... since all EMRs at some level are toolkits,
dirty little secret #7).
In my experience, across several vendors, this bad news is
often a show stopper. Especially when go-live is seen and funded as the end of the project, rather than the beginning of the EMR utilization project. It takes time and attention to use most tools well. Not necessarily a lot of time, but some. Some physicians get this and seem to need zero training. Others, despite training, just find the EMR exasperating. We all know both types! See
Homework First for more on the planning side.
As suggested by this blog's graphic, achieving and assuring physicians have a fast EMR is itself a deliberate competency that requires attention. There are Gremlins, and I'm not talking about the
I'm not even going to attempt to succinctly address performance monitoring and related performance issues, but I think the Gremlin(s) analogy is apt. The Gremlin is the wireless, or the relatively underpowered PC, or an unrelated applications memory leak, etc. Aside from training to ensure effective use of an EMR, identifying and dealing with assuring performance are important. This issue comes up multiple times per year for every vendors' EMR at every hospital when their use of the EMR is increasing.
In that respect, it's a healthy sign of progress. Somehow, it never quite feels healthy!
I'm very interested in this community's thoughts on this topic.