Gremlins: Immediacy and HCIT | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Gremlins: Immediacy and HCIT

July 3, 2009
by Joe Bormel
| Reprints

“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

AMC car popular in my youth.

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.



I just got a off the phone with my friend Mark. He has held executive positions with several organizations who have rolled out a variety of EMRs. He was vary familiar with the problem described in this post, the "All Full" view. His humorous retort is that it can and should alternatively be referred to as the "Awful" view.

Apparently, I'm not the only person who has had to bow to the wishes of important users, even when the result is awful.

Thanks for your detailed responses. Just what the doctor ordered pun intended. I really do appreciate your taking the time to get all my wheels back on the track. Much more comfortable now. That third reply you made was particularly thought provoking, especially toward the end.


Thanks for the kind words Frank.

There is increased flexibility issue which you described.

There's also the issue of products handling more context. When you work with a product, using the functions that it's designed for, it can work great.

The flip side is what I call The GPS Problem. A GPS is usually spot on. But, when it's maps do not match reality, or it doesn't know about traffic, road construction, or other factors, it's just plain wrong. Or, even more frustrating, when the road signs conflict with the GPS. The signs are usually right, but not always.

I see software increasing taking on that behavior - it's getting faster and more appropriate ... when it's not, it's more frustrating than before we were relying on it!

Jack, thanks once again for your thoughtful comments.

In the interest of clarity, I'm going to separate my replies across a few comments.

The important users reference:

I need to provide a little bit of background here. We, like most other large EMR vendors, in the course of new products and new releases, have in effect created many electronic medical records systems.

So, when we designed our first brand-new web solution for positions in 2001, it wasn't our first attempt. We and most of our clients had relevance prior experiences to draw from. That included knowing what physicians need from electronic medical record in a wide variety of care settings.

After we developed our vision and our requirements documents, we brought in the international design firm Electronic Ink ( to help us get the user experience right for physicians. We documented every daily use case, required use cases, and required workflows. We went through wireframe stages, video recorded a variety of physicians using one-way mirrors, and written scripts which reflected the user experience and user interface design.  There were lots of other steps I'm omitting for brevity.

Login was a pretty quick process. Once logged on, there was a single click way to get to a screen that, where logically possible, completely addressed the daily use case. For example, the position could immediately open the patient's chart in the context of new lab results they've not yet seen but expected, new reports, notifications of abnormal or critical results, or a view that summarized the patient that matched each physicians individual preferences.

As I stated in the original post, we know that many physicians like to start by looking at the bedside numbers. Hundreds of hospitals using a wide, summarized below from CLINT methodology (

Despite this exquisite attention to end-user needs, physicians and client organizations insisted on having all results for all time (all encounters) available in one, long scrolling screen. I know from my colleagues at working at other vendors, as well as from a number of CMIOs using a variety of products, this is not unique.

To quote my friend and colleague Marion Ball, when introducing new technologies, you must replicate the familiar, innovate on that base, and then transform based on what the new technologies can support. It's comfortable, convenient, and tempting to skip the replicate step. It's rarely possible.... That in part, is how we get to the non-requirement to show all information in one, long, scrolling display.

Dr. Joe,
Your post started out looking relatively simplistic, but you certainly ended by covering a significant amount of ground!

I think few would disagree that response time performance is an industry-wide issue that transcends HCIT. Look at the mess Microsoft created when it released Vista. Not only did it raise unprecedented issues with response time performance, it relegated a high percentage, if not the majority of otherwise perfectly good PCs to the scrap heap. At best irresponsible, and more than somewhat elitist.

That said, we all have ever-increasing expectations based upon the rising breath and depth of what's available to us on the Web. I remember when Google's default search page was blank and I liked it. Now it seems as though everyone has an iGoogle Web page and we're still not satisfied. Okay, fine. But at times, actually quite often, I have simple questions needing simple answers. You make an important point about alternatives that can't be overlooked.

To get a bit more focused, we deal primarily with issues surrounding HCIT on this site. And you raise an interesting number of questions in this post. I'm, for one, am most interested in your answers!

You say that "most•bCrLf modern EMRs have been designed to support multiple workflows, but the problem is training. Further, you embellish this by stating that hospitals and vendors are "forced by important users•bCrLf into building the kind of systems that impede the use of "fast and easy•bCrLf workflow features. Aren't most of the "important users•bCrLf the docs, and if so, if they're not satisfied with the end product, is it not the responsibility of the hospitals and the vendors to educated them about EMRs at the front end, rather than trying to train them, for lack of a better term, at the back end in order to change their expectations?

Most, I think, would agree that setting reasonable, achievable expectations at the onset, before a contract is awarded, is preferable. This should make the stakeholders' buy-in more realistic, reduce the ridiculous consultant costs associated with overly complex EMR implementations, and make clear that the go live is not the end, but just a step in the process of long-term, total commitment to the system.

What am I missing here? I fully realize I'm more than a little ignorant in terms of hard facts surrounding this topic. But it seems to me that although there are blatantly apparent gremlins in the hardware and software currently available that must be dealt with, the real gremlins may be the "important users.•bCrLf Can you please set me straight?


Good post...and the moral to the story is:

Flexibility has a price, it cost in design, in more testing, in more complex demos. Much more training and more in maintenance.

Are we as an indusrty willing to pay the price? As grandpa used to say - pay me now, or pay me latter..but you will pay!

Jack, regarding "... is it not the responsibility of the hospitals and the vendors to educated them about EMRs at the front end, rather than trying to train them, for lack of a better term, at the back end in order to change their expectations?"

Best practice is that training is on-going.

1. Front-end, train the physicians to do the one, two, or three things that are supported at go-line. Often, that's new results and document review and, ideally e-signature.

To avoid the "all full"/"awful" views that take forever problem (thanks again Mark, for the term of art), some pre- and post- front-end on-boarding work is necessary. That's elbow-to-elbow and over-the-shoulder work to make sure people are using the products relatively effectively.  (That means virtual screen sharing in the remote web world.)

2. There's "middle-end" work, adding functionality to the repertoire.

3. I think you're right about "back-end" training.

Jack, as you probably know, there is a powerful cultural overlay that the trainers have to address. It's a combination of the physician "CrazyBusy" problem, with the abandonment syndrome. The later refers to the case where the physician felt that they needed support and didn't get it. They may have even been entitled to that support. People have a long memory.

You made a distinction between the problem for vendors and the problem for hospitals.  You're right!  They are overlapping but different.  The vendor has to get both the design right, as well as respond on an on-going basis to issues.  The hospital's challenge is to invest in their own staffing and training, as well as make their hospital the best place to practice medicine as well as receive care.  That's an extremely high hurdle.  When (not if) executives fall off their horse, the first place to look is staffing and training.

It's critical to invest in assuring good experiences today and going forward. That, along with maintaining communication is the only ways I know of to build or rebuild trust.