Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

NIST Dissects Workflow: Is Anyone Biting?

Psst. Hey, Buddy, wanna see an EHR, visit’s workflow? Here it is, thanks to the National Institutes of Standards and Technology’s (NIST) new report, NISTIR 7988, Integrating Electronic Health Records into Clinical Workflow, etc.

Returning Patient Ambulatory Workflow NIST

What It Represents

NIST wants to make EHRs usable and useful. It first took aim at patient safety EHR functions that endangered, confused users or were error prone. To counter these, it developed and recommended EHR usability protocols.

Now, in an extensive report, it’s tackled EHR workflow to determine where problems occur. The result is a comprehensive work with significant findings and recommendations. The question is: Is anyone listening?

NIST’s Analytical Approach

NIST decided to create a typical workflow by interviewing knowledgeable physicians, who it calls Subject Matter Experts, SMEs. The physicians had different specialties and used different EHRs, though who they were, NIST doesn’t say.

From their discussions, NIST’s analysts created the above chart, NIST’s Figure 2. NIST’s authors recognize that actual workflows will vary based on setting, sequences, staffing, etc., but that it provides a useful way to look at these issues.

What They Did With It

Working with their physicians, NIST’s analysts broke down the workflow into three sections: before, during and after the visit. Then, they broke down, or decomposed, each of those sections, like opening nested Russian dolls. For example, they segmented the physician’s encounter, below, and once again, broke each down into its functions.

Returning Patient, Physician Encounter - NIST

What They Found

It was at this stage the analysts found significant variations among the EHRs used by their physicians,

[T]here appeared to be high variation in whether and how the EHR was used during this period, how extensive each of the activities typically were for each SME, different based upon the type of patient, how complex the patient was, context of how busy the day was, and other factors. NSTIR 7988, p 18.

Despite these differences, the physicians identified two issues that crossed their EHRs:

  • Working Diagnoses. The physicians wanted systems that let them create a working diagnosis and modify it as they worked until they made a final diagnosis. Similarly, they wanted to be able to back up and make changes as needed, something current systems make hard.
  • Multiple Diagnoses. Diagnoses usually involve multiple causes, not single factors. They wanted their EHRs to support this.

These types of issues aren’t new to those familiar with EHR problems. What’s new is NIST, as an independent, scientific organization, defining, cataloguing and explaining them and their consequences.

What They Recommended

From this work, NIST’s analysts developed extensive and persuasive recommendations, in three categories:

  • EHR Functions
  • System Settings, and
  • System Supports

EHR Functions

NIST’s recommends reducing practitioner workload, while increasing their options and supports. For example, they suggest:

  • Workload Projections. Give practitioners a way to see their patient workloads in advance, so they can plan their work more effectively
  • Notes to Self. Let users create reminder notes about upcoming visit issues or to highlight significant ,patient information. These would be analogous to their hand written notes they used to put on paper charts.
  • Single Page Summaries. Create single page labs summaries rather than making users plow through long reports for new information.
  • Single Page Discharge Summaries. Eliminate excessive boiler plate with more intelligent and useful discharge sheets.
  • Highlight Time Critical Information. Segregate time critical information. Often they get mixed in with other notices where they may be overlooked or hard to find.
  • Allow Time Pressure Overrides. When time is critical, EHRs should allow skipping certain functions.
  • System Settings

NIST recommendations echo the familiar litany of issues that characterize poor implementations:

  • Allow Patient Eye Contact. Exam room designs should put the doctor and patient in a comfortable, direct relationship with the computer as a support.
  • Login Simplification. Allow continuous logins or otherwise cut down on constant login and outs.

System Supports

The physicians recognized they often caused workflow bottlenecks. NIST recommended off loading work to medical assistants, nurse practitioners, physician assistants, etc.. For example, physician assistants could draft predicted orders for routine situations for the physician to review and approve.

Progress Note Frustrations

In the thorny area of clinical documentation, the report details physician frustration with their EHRs. All experienced excessive or missing options, click option hell, excessive output, puzzling terms, etc. These were compounded by time consuming system steps that did not aid in diagnosis or solving patient problems. The report discusses their attempts at improving documentation:

Several of the SMEs had attempted and then abandoned strategies to increase the efficiency of documentation. One SME reported that copying and pasting and “smart text” where typing commands generate auto-text had a “vigilance problem.” The issue was that it would be too easy to put the wrong or outdated information in or in the wrong place and not detect it, and then someone later, including himself, could act on it not realizing that it was incorrect.

One physician described an attempt to use automated speech recognition for dictation for a patient with scleritis, which is inflammation of the white of the eye. He stopped using the software when what was documented in the note was “squirrel actress.”

Another SME described that colleagues relied upon medical assistants to draft the note and then completed it, but they did not like that approach because it was too tempting to rely upon what was typed without reviewing it, and he felt the medical knowledge level was not high enough for this task.

One SME described a reluctance to use any scribe, including a medical student, because the risk would be too high of misunderstanding and thus not correctly documenting the historical information, diagnosis, and treatment plan. This was particularly problematic if the physician had information from prior visits, which contributed to these elements, which were not discussed in detail during the visit. NSTIR 7988, p. 28

Coding their diagnoses into progress notes also came in for criticism:

All SMEs described frustration with requirements to enter information into progress notes, …, which were applied to the notes in order to have sufficient justification to receive reimbursement for services. Although all of the SMEs acknowledged the central importance of receiving reimbursement in order to function as a business, this information was often not important for clinical needs. NSTIR 7988, p. 28

Role Based Progress Note

Unlike other areas of the report, the doctors could not agree on what to do, nor does NIST offer any specific cures for documentation problems. Instead, NIST recommends using a new, role based, progress note:

[T]he progress note for a primary care physician would have a different view from a specialist such as a urologist physician, who might not need to see all of the information displayed to the primary care physician. Similarly, the view of the note for primary care providers could differ from the view of a billing and coding specialist. … NSTIR 7988, p. 28

Will ONC Respond?

In this and its prior reports, NIST covers a lot of EHR issues making sensible recommendations that not only improve functionality, but more importantly improve patient safety. However, NIST’s recommendations are just that. It’s not a regulatory agency, nor is supposed to be one. Instead, its role is to work with industry and experts to develop usable, practical approaches to tough technical, often safety related, problems. To its credit, it’s done this in a vast number of fields from airplane cockpits, nuclear reactors, and atomic clocks to bullet proof vests.

However, its EHR actions have not gained any noticeable traction. If any EHR vendor has implemented NIST’s usability protocols, they haven’t said so. They are not alone.

Notably ONC, one of NIST’s major EHR partners, refuses to incorporate any of NIST’s usability recommendations. Instead, ONC requires vendors to implement User Centered Design, but does not define it, letting each vendor do that for themselves.

NIST has many answers to common EHR workflow and usability problems. The question is, who will bring them to bear?

March 26, 2014 I Written By

When Carl Bergman’s not rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Ideas, Insights and Predictions from Healthcare Social Media Thought Leaders

I thought it would be fun to experiment with a new type of blog post. I came up with the idea during the recent #HITsm chat. I decided I’d ask 5 of the #HITsm participants to share an idea, prediction, insight, or thought that I could share in a blog post. I didn’t give them a topic, direction, or ask any questions. I just asked them to share something that thought would be useful or interesting. I found the results quite interesting.

I asked 5 people to tweet something. Only 4 of the 5 responded (probably a lost Twitter DM), but one of the people sent two tweets. So, the following are the 5 tweets with a little bit of commentary from me.

This is a really interesting insight. Chad has a really good point. I’m not sure I’ve seen a truly open HIE that just wanted to be the company sharing the data. I think a few have that goal in mind, but they haven’t gotten there yet. It will be a real game changer when an HIE just wants to be the pipes and not the faucet as well. I will say that most healthcare organizations aren’t quite ready to implement the faucet though either.

Thank you Dr. Nan for bringing some humor to the post. I love it! Although, maybe it’s not that funny since it rings far too close to the truth. I might also share this with my wife so she understands age appropriate behavior for our children.

This was the other tweet that Dr. Nan sent. You can tell it comes from a raw place. I’m actually surprised we don’t talk about doctor depression more. I read a lot of entrepreneur blogs and there’s been a real increase in discussion around entrepreneur depression. I expect that doctors could really benefit from this discussion as well. For some reason there’s a fear of discussing the real challenges and pressures of the job.

Would we expect anything other than workflow from Dr. Webster? I’m not sure I like his prediction. I hope he’s wrong. I don’t want a workaround for EHR workflow. I want something drastically different.

I love this concept and refer to it as treating healthy patients. Although, I love Ryan’s approach of patients taking responsibility for their own health and engaging with those they love in health-generating behaviors. Sure, doctors are miracle workers, but we as patients should be much more involved in our health as well.

That’s all she wrote. If you like this idea, let me know. If you’d like to participate in a future post, be sure to tweet me @ehrandhit.

July 16, 2013 I Written By

John Lynn is the Founder of the blog network which currently consists of 15 blogs containing almost 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently launched two new companies: and, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus.

Balancing EHR Change vs Train

I was talking with Heather Haugen from The Breakaway Group (A Xerox company) today and in our discussion she used the word “train”, but I heard the word “change”. I always love a good play on words and so it was interesting for me to consider the difference between change and train in an EHR implementation.

Every EHR implementation I’ve been apart of walks a fine line between users wanting the EHR software to change versus the need for an EHR user to change. One of the most common phrases out of a doctor’s mouth during an EHR implementation is, “Why did the EHR vendor implement that feature like this? Did they not talk to a doctor? This makes no sense.” We’ve dug in previously to the concept of EHR vendors consulting doctors during their EHR development so we won’t go into that further now. Every EHR vendor consults doctors, but no two doctors practice alike. So, it’s normal that every doctor would wonder why certain features are implemented the way they are implemented.

When faced with this issue, the doctor is faced with an important decision with two options. The first option is to work with the EHR vendor and convince them to change how their EHR works. In a large hospital EHR vendor situation, this can be almost impossible. Plus, even if that EHR vendor does like your suggested change it’s going to take months and sometimes years before that change is implemented in the EHR software, tested, and released all the way to you the end user. Yes, these changes can go faster with a SaaS EHR, but it still will likely take months before the change reaches the end user.

In some cases, you can wait for the change to be made before using that EHR feature. However, more often than not a doctor is going to have to train on how the EHR vendor has implemented the feature. This highlights to me why having great EHR training is so important. Sure, many of the things in an EHR will be intuitive, but great EHR training is still always beneficial. EHR software is too complex to just pickup and use. Plus, even if you can use the basic EHR features, good training points out the ways to optimize the EHR workflow.

Most doctors don’t understand why various parts of an EHR workflow can’t be easily changed. They just think change should happen easily. Ironically, the doctor then proceeds to resist any change to how they want to work.

May 21, 2013 I Written By

John Lynn is the Founder of the blog network which currently consists of 15 blogs containing almost 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently launched two new companies: and, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus.

Three Tips For EHR Transitions

Moving a medical practice from paper to an EHR is no picnic.  Staff and physicians both may find the process difficult, and the changes they have to make to be threatening. But there are approaches you can take which can make the process easier.  Here’s a nice triad of suggestions from EHR implementation manager Amanda Guerrero:

* Make workflow changes gradual:

Too often, medical practices assume that they can implement an EHR without making major changes to their workflow.  The reality is, however, that many processes which worked fine on paper don’t work when you switch to using EHRs, Guerrero notes. So how do you go about making changes without upsetting and confusing staff and clinicians?  The idea, she says, is to make sure changes happen gradually. Giving people time to adapt to changes helps a lot with staff morale. (It doesn’t hurt to explain how the changes will benefit both staff and patients, either.)

Ask for feedback:

Bearing in mind that changes to workflow will have to be made, how do you choose which changes come first? One way, Guerrero says, is to ask the people who are using the EHR which processes are slowing things down the most.  Be sure, she recommends, to include doctors, nurses, front desk and even billing staff in collecting feedback — after all, virtually any part of the practice can be affected by the EHR.  Once you’ve figured out which areas are the most troublesome, arrange them in order of importance so you can take them on in the most effective manner.

Educate patients:

Now that Meaningful Use has pushed practices into making patient health data available to them, it’s time to encourage them to use it. That being said, patients may be overwhelmed by the amount of data being presented, especially when interpreting lab results, Guerrero suggests.  To reduce the impact of this change on patients, and avoid confusion, make sure you help them understand what they’re looking at and how it can help them improve their healthy, she says. And make sure let patients know you’re available to help answer questions.

May 20, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @annezieger on Twitter.

Physician Guidance for EHR Success

I want to take a look at the complaint I hear over and over and over again when it comes to EHR software. I’ve heard this comment said about every single EHR vendor out there. I’ve also heard it from doctors in every specialty and from every size organization. It comes in a few different forms, but all communicates the same idea. This is the doctor complaint I’m talking about:

Did the EHR vendor even talk to a practicing doctor when they developed this EHR?

Yes, the complaint is usually voiced as a question, but the question is lathered up with an unbelievable shock that an EHR vendor could misunderstand a doctor’s workflow needs so terribly. Plus, it’s reinforced with the belief that if the EHR vendor had somehow just talked to a doctor, any doctor, that this wouldn’t be the result.

Of course, the situation is much more complicated than that statement supposes. In fact, there’s a great thread on the HIMSS LinkedIn group that has a bunch of deep discussion on how to create a healthy partnership between providers and EHR companies.

One key to understanding this relationship is first that every single EHR company has consulted doctors (usually many many doctors) in the development of their EHR software.

Many doctors will then wonder how they could have an experience like the one I described above if the EHR vendor consulted a practicing doctor (and I assure you many many doctors have had the experience above). The answer to that question has multiple layers. The first layer that most practicing doctors see is that “most doctors that consult EHR companies aren’t really practicing doctors.” In many cases, this is definitely the case. Many Chief Medical Officers at EHR companies have made EHR their full time job and no longer practice medicine. Many physician founded EHR companies have a physician leading the company that no longer practices medicine. Certainly some portion of the EHR workflow disconnect could be related to non-practicing providers driving the EHR development process, but that’s just one layer.

The second layer is that in every case I’ve seen there’s always been practicing providers involved in the EHR development process as well. They are active in user groups. They sit in focus groups. EHR vendors go to the practicing physician’s office to learn from them first hand. Most EHR companies really do make a sincere effort to understand the practicing physicians and not just try and guess at what the practicing physicians want.

Another layer to this problem is translating what the practicing physician requests into the EHR workflow. Now imagine that two practicing physicians request the polar opposite feature (yes, this happens a lot too). How then do you translate that feature into something that’s going to satisfy both physicians. That’s not an easy thing to accomplish.

The next challenge to consider is that many physicians aren’t technically astute enough to know what they want. When this is the case, they don’t know what they should even be asking for. I’m sure many doctors will scoff at this idea, but it’s the same concept for programmers. Many programmers aren’t technically astute enough to understand the medical world well enough to develop what the doctor wants. It’s a two way street and is why it’s so important for EHR companies to create an amazing collaboration between the right doctors and the right programmers. That’s a special breed of person that is not easily found.

Of course, I haven’t even mentioned the specialty layer. A technically astute practicing physician in cardiology will likely do a terrible job designing an EHR workflow that works well for pediatrics, OB, and general medicine. If you thought it was hard creating an EHR workflow that works for all the doctors in one specialty, now try and do that across 40+ medical specialties.

If you remember back to the paper chart world (which many of you are still living in), how come we didn’t have a standard paper form that every doctor used to document the visit? In fact, it was pretty rare that any 2 non-affiliated clinics used the same form at all. Sure, some forms were exchanged at the medical societies, but in most cases each clinic wanted to modify the form to fit their own clinic’s needs and desires. This happens in the EMR world to some extent, but it takes more training and skill to modify an EHR workflow than the Word document you got from your colleague. Plus, many don’t want to invest the time to make those modifications.

I’m not trying to put the blame for this on anyone in particular. Plus, I don’t want to make this sound like an excuse for EHR vendors to be lazy in how they approach their EHR development. We can be sure that some of the issues I describe above aren’t because the doctors didn’t provide good requirements and not because the programmer didn’t know how to meet those requirements. Some of the problems we see have to do with a combination of rushed release times or lazy programming (which are related). When this is the case, EHR vendors should take it on the chin and deal with the issues rather than trying to blame someone else.

With that said, hopefully I’ve made clear that it’s not enough for an EHR vendor to just consult a practicing physician. If that was the case, then all 300+ EHR companies would have beautifully designed EHRs that physicians’ love. Instead, I think the fact that so many of the 300+ EHR vendors have this issue, it illustrates how hard it is to get a technically astute practicing physician that can get programmers to make a beautiful interface that applies across all specialties.

From now on, I hope to hear physicians who have this problem change their question to, “Did the EHR vendor even talk to a technically astute practicing doctor in my specialty that works the way I like to work and practices medicine the way I like to practice medicine and bills the way I bill and in the region I live when they developed this EHR?” Then, we’ll all be able to easily answer “No, it seems like not.

February 14, 2013 I Written By

John Lynn is the Founder of the blog network which currently consists of 15 blogs containing almost 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently launched two new companies: and, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus.

No EHR Training Needed

Anne Zieger over on EHR Outlook just posted an article talking about the need of training on an EHR. In the article, she quotes Dr. Bertman, CEO of EMR company Amazing Charts (Full Disclosure: They’re a sponsor of this site). Here’s one excerpt from the article:

According to Dr Jonathan Bertman, if you need extensive training to use an EHR, you shouldn’t buy it. “Doctors know how to be doctors,” he says. “They shouldn’t have to be trained to be software technicians – if they need training than it’s not a good thing.”

Here was my response in the comments of the article (and a little additional commentary for this post):
I have a feeling Dr. Bertman and I agree about training, but I think it’s over the top for him to say, “if they need training than it’s not a good thing.” Certainly many EHR software vendors require far too much training. I think that’s the point he’s trying to make and I agree 100%. However, the reality is that there are a whole lot of people that get training even on Office. In fact, there’s a whole entire industry around training on Office products. So, EHR is going to have training as well.

Another excerpt from the article:

“Compare them to Microsoft Office,” Dr. Bertman suggests. “It’s a powerful tool, but you usually don’t need special training to use it. An EHR is not more complicated than Office, and that’s how we should be looking at them.”

I’d generally disagree that an EHR is not more complicated than Office. The reality is that what you want to do in an EHR is more complicated than Office. Sure, if all I want to do is type a little bit and maybe click bold, then I’m fine. Most EHR you don’t need any training to login, browse their appointment grid, browse patients, and even create notes.

The reason for the EHR training that’s out there isn’t for these simple features. It’s for the more advanced features like is done in most Office trainings. I could be wrong, but I believe Dr. Bertman generally agrees with me on this, but it wasn’t expressed in a short quote from him.

One other interesting point is that I think a lot of people call it EHR training when in fact it’s about EHR workflow planning and training. You’re a brave person to implement an EHR without planning out your current workflows and how they’ll map to an EHR workflow. I often see this workflow planning and training covered under the broad definition of EHR training.

October 6, 2011 I Written By

John Lynn is the Founder of the blog network which currently consists of 15 blogs containing almost 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently launched two new companies: and, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus.

Listen to the Local Tribal Medicine of a Practice During an EMR Implementation

At the recent Health Tech Next Generation conference that I attended, I heard someone refer to the “local tribal medicine” practices that are found in a practice.

I found the description incredibly intriguing and descriptive. It’s an incredibly apt description of many of the practices and norms that exist in a medical practice. Each practice has created what becomes an almost tribal mentality when it comes to people’s passion for existing workflows and processes. [It's worth clarifying that it's tribal as far as people's passion for doing the workflow. Not because the practices and workflows themselves are tribal.]

I guess this is a natural thing that happens not only in medical practices, but throughout life. We grow accustom to certain processes and practices and so they start to feel really comfortable. Changing them can throw people for a loop even if you exhibit incredible care in the process.

I was recently asked by a reader whether I thought it was better for EHR vendors to look at changing the current operations to match the EHR workflow or whether it was better for EHR vendors to adapt to the current clinic workflow. Here was my response:

It’s an interesting dynamic. Part of it depends on the type of clinic that you’re dealing with. Sometimes a clinic has such terrible workflows that they need to be fixed before you apply an EMR. Otherwise, it will exacerbate the clinical workflow problems and cause some real pain.

However, I generally think it’s best to try and mimic the current process as much as possible when first implementing an EMR. Point being that you should cause as little disruption as possible. Although, it’s best when there’s some flexibility with this approach. Some things are possible in the electronic world that weren’t possible in the paper world and so there’s no reason to delay implementing those benefits when they’re pretty obvious.

Then, I suggest taking a look at the EHR system and how it’s working about a month (sometimes even a bit sooner) after implementation. At this point the clinic is proficient enough to talk about all the EMR features they were too overwhelmed to implement at the beginning.

Then, 9 months to a year out you can do another review to see what processes would be more efficient or could leverage technology better than you’re doing already. I’ve found that this review is when doctors really start to love their EHR and really start to see the value of using an EHR in their clinic.

In summary, I agree with modeling the current clinical workflow as much as possible to start, unless the practice is a mess. Then, I suggest evaluating those clinical workflows after the clinic has experience using it.

I’d love to hear your thoughts. How do you deal with the local tribal workflow of a practice? Do you want to change them during the EHR implementation or wait to make the changes?

August 16, 2011 I Written By

John Lynn is the Founder of the blog network which currently consists of 15 blogs containing almost 5000 articles with John having written over 2000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 9.3 million times. John also recently launched two new companies: and, and is an advisor to docBeat. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and Google Plus.