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!

Not All EHR Clicks Are Evil

There’s a great blog post on HIStalk that is a beautiful CMIO Rant. He provides some really needed perspective on the issues with EHR software. In many ways, the post reminded me of my post titled “Don’t Act Like Charting on Paper Was Fast.” In that post, I highlight the fact that far too many people are comparing EHR against doing nothing versus comparing EHR against the alternative. Those are two very different comparisons.

The money line from the CMIO rant was this one:

If we insist that all clicks are wasted time, then we can’t have a conversation about usability, because under the prescription pad scenario, the only usable computer is one you don’t have to use at all.

I love when you take something to the extreme. It’s true that we all want stuff to just happen with no work. That’s perfect usability. However, that’s just not the reality (at least not yet). If we want the data to be accurate and to be recorded, then it takes human intervention (ie. clicks). Some clicking is necessary.

The CMIO goes on to say that the key to EHR usability is expectations. I thought that was an interesting word to describe EHR usability. I’ve written about this topic before when I compared the number of EHR clicks to the keys on a piano. In that article I suggested that the number of clicks wasn’t the core issue. If we could create EHR software that was hyper responsive (like a piano key), was consistent in its response speed, and we provided proper training, then having a lot of EHR clicks wasn’t nearly as big an issue.

Not that this should be an excuse for EHR vendors to make crappy software. They should still do what they can to minimize clicks where possible. However, the bigger problem is that we haven’t achieved all three of these goals. So, we’ll continue to hear many people complaining about all the EMR clicks.

April 11, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com 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: InfluentialNetworks.com and Physia.com, 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.

Scribes and Problems with the Healthcare System

In a recent #HITsm chat we had a pretty good discussion about scribes and their place in healthcare. I know a lot of people that are really big proponents of scribes, but I also know many people who are against them.

During the discussion, the question was asked if scribes mask the problems of the EHR software. This was my reponse:

If I were to do that tweet again, I might replace healthcare system with reimbursement system. Scribes are a mask to the fundamental problems with how we pay for healthcare. I’ve always loved to think about what an EHR would look like if it didn’t have to worry about billing. It would be a completely different system than what we have with EHRs today.

The reality is that doctors want to get paid and so EHRs have to deal with billing. Plus, now they have to deal with meaningful use regulation as well. Add those two together and you can understand why scribes are so popular with doctors.

Every single EHR would be better and easier to use if they were just worrying about providing a tool to doctors that lets them document the visit and ensure quality patient care. However, until that happens (which is never) scribes and other alternative methods to document are going to be very popular with many physicians.

April 8, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com 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: InfluentialNetworks.com and Physia.com, 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.

Reply to Dr. Jacob Reider on NIST Dissects Workflow: Is Anyone Biting?

One comment on my latest post, NIST Dissects Workflow: Is Anyone Biting?, deserves a more than casual reply.

Here’s the comment from Jacob Reider (Note: Dr. Reider is ONC’s Acting Principle Deputy National Coordinator and Chief Medical Officer. He has made major contributions to the HIT field and is one of its significant advocates.)

Carl, ONC’s UCD requirement references ISO 9241–11, ISO 13407, ISO 16982, NISTIR 7741, ISO/IEC 62366 and ISO 9241–210 as appropriate UCD processes.

We also require summative testing as defined in NISTIR 7742.

Might “Refuses to incorporate NIST recommendations” be a bit of an overstatement?

We solicited public comment in our proposed rule for 2015 certification and would welcome specific suggestions for how we can/should improve user experience of health IT products for efficiency and safety.

Dr. Reider, thank you for your comment – it certainly falls into the category of you never know who’s reading.

Let’stake a look at your last comment first, “Might ‘Refuses to incorporate NIST recommendations’ be a bit of an overstatement?”

Obviously, I don’t think so, but I am not alone.

I based my comment on ONC’s statement in its rule making that refers to NIST’s usability protocols. It says:

While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” (21) we are concerned that it would be inappropriate at this juncture for ONC to seek to measure EHR technology in this way.

Sounds like a rejection to me, however, don’t take my word. Here’s the AMA’s response to this decision. First, they demur and quote ONC:

We disagree with ONC’s assertion in the Version 2014 final rule that, “[w]hile valid and reliable usability measurements exist, including those specified in NISTIR 7804 ‘‘Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,’’ we expressed that it would be inappropriate for ONC to seek to measure EHR technology in this way.”

It then says:

To the contrary, we believe that it is incumbent upon ONC to include more robust usability criteria in the certification process.  The incentive program has certainly spurred aggressive EHR uptake but has done so through an artificial and non-traditional marketplace.  As a consumer, the physician’s choice of products is limited not only by those EHRs that are certified but also by the constraint that all of these products are driven by federal criteria.  The AMA made several detailed recommendations for improving Version 2014 certification in our Stage 2 comment letter, which were not adopted, but still hold true, and we recommend ONC consider them for the next version.  Testimony of AMA’s Health IT Policy Committee’s Workgroups on Certification/Adoption and Implementation, July 23, 2013, pp. 5-6

I recognize that ONC says that it may consider the protocols in the future. Nevertheless, I think the plain English term rejected fits.

In the first part of his statement, Dr. Reider cites several ISO standards. With the exception of the Summative Testing, all of these have been referred to, but none have been adopted. Reference to a standard is not sufficient for its inclusion under the operation of the federal Administrative Procedure Act, which governs all federal agency rulemaking. In other words, these standards are important, but ONC simply calls them out for attention, nothing more.

I think two factors are at work in ONC’s reluctance to include the NIST usability protocols. The first is that the vendors are adamantly opposed to having them mandated. However, I believe there is a way around that objection.

As I have argued before, ONC could tell vendors that their products will be subject to a TURF based review of their product for compliance and that the results would be made public. That would give users a way to judge a product for suitability to their purpose on a uniform basis. Thus, users looking at the results could determine for themselves whether or not one or more non compliance was important to them, but at least they would have a common way to look at candidate EHRs, something they cannot do now , nor under ONC’s proposed approach.

The other factor is more complex and goes to the nature of ONC’s mission. ONC is both the advocate and the standards maker for HIT. In that, it is similar to the FAA, which is vested with both promoting and regulating US aviation.

It’s well established that the FAA’s dual role is a major problem. It’s hard to be a cheerleader for an industry and make it toe the line.

With the FAA, its dual mandate is exacerbated when the highly respected NTSB investigates an incident and makes recommendations. The FAA, acting as industry friend, often defers NTSB’s authoritative and reasonable recommendations to the public’s determent.

I believe that something similar is going on with ONC. NIST’s relationship to ONC is roughly analogous to that of the NTSB’s to the FAA.

NIST is not an investigative agency, but it is the federal government’s standards and operations authority. It isn’t infallible. However, ONC dismissing NIST’s usability protocols, in one word, inappropriate. It did this without explanation or analysis (at least none that they’ve shared). In my view, that’s really inappropriate.

ONC has a problem. It’s operating the way it was intended, but that’s not what patients and practioners need. To continue the aviation analogy, ONC needs to straighten up and fly right.

March 31, 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 EHRSelector.com, 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.

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 EHRSelector.com, 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.

An Eclectic Gathering of EHR Usability and Project Resources

Here are a few resources that I use to solve a variety of design, project management and other problems. Some, such as NIST’s protocols, are directly EHR related; others aren’t, but easily apply to EHR problems.

So here, as was once said, are a few of my favorite people and things:

  • Dan Bricklin. Hopper and Jobs are gone. Woz is a sage. Gates, Kapor and Norton long ago stopped being systems innovators in favor of being philanthropists. Bricklin, however, the electronic spreadsheet’s inventor, soldiers on. His personal site has much to offer, especially his video on interface development for different types of devices and users.
  • Donald Norman. If you only read one of Norman’s many works on usability, make it The Design of Everyday Things. When you do, you’ll find one of the most cogent, funny and thoughtful studies of user centered design. From his account of slide projectors from hell, to post office doors that trap the unwary, to the best ways to arrange light switches, Norman has good advice for all of us. I first read this twenty years ago, but the advice still resonates. He’s recently revised it and added a free on-line course. After Norman, you won’t look at doors, appliances, much less screens the same way again.
  • Jakob Nielsen. There are people who think if you know Nielsen’s usability approach, you need little else. Then, there are those who think if you know Nielsen’s approach, all hope is lost. No one has a monopoly on good interface design, but Nielsen’s site is a place to stop for tons of notable examples.
  • NIST Protocols. NIST works with the private sector to solve major, operational problems. After Three Mile Island close call NIST redesigned all US nuclear power plants’ control rooms. Recently, they’ve developed EHR usability standards. These are the best, most comprehensive treatment of what not to do. You’ll find them in an appendix in their publication, NISTIR 7804.
  • ONC Repository. Most those in the EHR field know ONC, for better or worse due to its Meaningful Use standards. There’s a lot more. Buried on ONC’s site is its Implementation Resources. The repository has dozens of videos, guides, white papers, toolkits and templates all centered on improving EHR selection, implementation and use.
  • Ross Koppel. Koppel is a grouch. He grouches about the dozens different ways EHRs record simple things, such as, blood pressure. Writing often in JAMA, he notes how health IT systems spawn workarounds, confusion and give users choices that are false, misleading or illogical. In short, he’s produced a treasure trove of frightening observations, embarrassing questions and pointed observations, but his bête noire findings also include correctives. All of this is written in a careful, thoughtful style that makes the subject compelling and chilling.
  • Tom Demarco. Demarco of the Atlantic System Guild has produced a wealth of insightful books, lectures and articles on project management. In the 60s, DeMarco asked himself, if a civil engineer can build a bridge from requirements to operation, why can’t we do the same thing with software. His first take was Structured Analysis and System Specification. It’s still in print and full of practical advice and approaches for project managers. Other works include Peopleware: Productive Projects and Teams, where he takes the odd position that you should treat your staff like people and help them be productive. I especially love his The Deadline: A Novel About Project Management in which the main character is kidnapped and forced to manage a project under threat of death. It’s a comedy.

Interested in EHR usability? Join my LinkedIn group: EHRUsability.

March 10, 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 EHRSelector.com, 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.

Defining EHR Usability Isn’t for the Timid

Editor’s Note: A big welcome to Carl as a writer on EMR and EHR. He’s been writing guest posts across the Healthcare Scene network for many years, but we’re happy to have him now writing formally on EMR and EHR. You’ll be able to read all of Carl’s past and present posts on EMR and EHR here.

Sometimes it seems that EHRs and usability are like Earth and Mars. Their orbits get relatively close, but they’re never going to occupy the same place and time.

Of course, the two we’re occupied with aren’t cosmic equals. EHRs are specific systems, while usability is, at best, a concept with various definitions. In fact, the closer you get to a definition of usability the less focused it becomes. My late brother used to call things like that, “Far aways.” “The farther away you get the better they look.”

Indeed, most definitions of usability say it’s something that’s useful. Ugh. So, is there any way to bring some clarity to its definition, so it has greater precision?

Doing so, I think, requires not only defining what usability is, but also tackling when it’s not present what’s wrong.

Usability: A Different Definition Approach

Most definitions of usability I’ve seen push the issue off onto use or useful. That is, usability is defined as something that is useable. This isn’t far from using a word to define itself, which was a grammar school no no. It also fails to involve the user’s expectation. I would define it this way:

Usability is the ability of a system to supply a desired result with the minimum necessary information, conditions or steps.

This definition hinges on a user getting what they want expeditiously. Simply put, usability means no unneeded fuss or feathers. As I look at it, usability is to systems what parsimony is to logic. In logic, the simplest explanation that explains the occurrence is the best. Similarly, the most usable system is the one that requires the least effort to supply the correct response.

User Hostile Systems

If I left matters at this juncture, however, I wouldn’t have addressed a major related issue. When a system is user hostile, just where has it gone wrong. Each of us has experienced or heard these tales. You make a simple request and wind up in wilderness of documentation or your options are have everything but what you want.

These are negative examples of usability. It is, however, not enough to just stamp them as such and move on. It’s also important to say exactly where usability fails. To get a handle on these issues, I divide them into three classes:

Class One: Bug. Generally, a computer or software bug is anything that caused a wrong or unexpected response. I take a narrower view. To me, a bug represents a properly designed system that’s incorrectly implemented. That is, the program code fails to carry out the system designer’s intent. For example, you click Print and the system emails your Aunt Edna.

Class Two: Design Failure. In these, the code is OK, but the requirements failed. The classic refrain for these is, “ Yes, that‘s what I asked for, but it isn’t what I wanted.” Fixing these, unlike bugs, requires correcting the requirements and conforming the code.

Class Three: Missing Requirement. Sherlock Holmes in the Silver Blaze mystery had this to say about EHR usability:

“Is there any point to which you would wish to draw my attention?”
“To the curious incident of the dog in the night-time.”
“The dog did nothing in the night-time.”
“That was the curious incident,” remarked Sherlock Holmes.

Nothing is less usable than something that doesn’t exist. It’s not a matter of getting wrong. It’s a matter of not getting it at all.

What makes this a difficult category to apply is the issue of user need. What some users think is fundamental, others may regard as a frill or not necessary at all. Usability, therefore, hinges on neither design nor programming but on policy. However, if policy deems the function important, then its omission is far more serious than the other two categories.

An example. I use a large practice associated with a local medical school. It uses Jardogs’ Followmyhealth (FMH) web portal. It conveniently combines PHR, email and scheduling. I especially like being able to email my PCP. Recently, however, I ran into a class three problem.

FMH lists my PCP and any other of my providers. My PCP suggested I see a specialist for a problem. I went to FMH to find a list of specialists and phone numbers. I got nowhere. I could remove a provider, but not find a new one. I searched FMH’s knowledge base for provider and got 40 hits, but nothing on finding one. I then went through the FMH Patient Guide again without luck. Frustrated, I left the system and went to the practice’s public web site. It had the list. I found the department and number I wanted. Once I got set up, the new provider appeared in FMH.

Wondering if I had missed something, I called support with the problem. The support rep spent several minutes, came back, and confirmed that it could not be done, which surprised him. He agreed they should at least have a link in FMH to search for providers. Whether FMH adds it, of course, is a policy question.

December 30, 2013 I Written By

When Carl Bergman’s not rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, 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.

EHR Usability: Is There a Right Path?

The following is a guest post by Carl Bergman from EHR Selector.

Earlier this fall, the AMA sponsored a Rand Corporation study on physician’s professional satisfaction. Based on interviews with physicians in 30 practices, the study covers a variety of topics from workplace setting to quality of care, EHRs and health reform, etc. At the time, the report generated discussion about dissatisfaction in general with EHRs and MU in particular.

Usability, Part of MU?
Overlooked in the discussion was a new and important recommendation on usability. Here’s what is says:

Physicians look forward to future EHRs that will solve current problems of data entry, difficult user interfaces, and information overload. Specific steps to hasten these technological advances are beyond the scope of this report. However, as a general principle, our findings suggest including improved EHR usability as a precondition for federal EHR certification. (Factors Affecting Physician Professional Satisfaction and Their Implications for Patient Care, Health Systems, and Health Policy, p.142) Emphasis added.

It would be overkill to say that this represents adopted AMA policy, however, it’s not overkill to say that the recommendation is part of a project that the AMA initiated and supports. As such, it is most significant that it recognizes the need to bring some coherence to EHR usability and that the MU system is the logical place to put it.

Changing the Vendor – User Relationship
One commentator who did notice the recommendation was EHR Intelligence’s Robert Green. In his review, Green took a different tack. While agreeing that usability needs improvement, he saw a different way to get change:

Usability remains an enigma in many clinic-EHR vendor relationships because it hasn’t been nearly as important in the recent years’ dialogue as “meaningful use.” But among the competing priorities, usability among physicians and their EHR vendor is a real opportunity to develop shared expectations for a new user experience.

As a patient, I would rather not see the delegation of the “usability” dialogue of EHR to those in the roles of meaningful use certification. Instead, physicians who have spent many years of their lives learning how to “take care of patients” could seize the moment to define their own expectations with their EHR vendor of choice within and beyond their practice. (How connected is EHR user satisfaction to vendor choice?) Emphasis added.

I think these two different paths put the question squarely. They agree that usability needs increased action. Users have gotten their message across with alacrity: all systems fail users in some aspect. Some fail catastrophically. Though some vendors take usability to heart, the industry’s response has been uneven and sporadic.

Where these two approaches differ is tactics. Rand looks at usability, and sees an analog to MU functions. It opts for adding usability to MU’s tests. Green sees it as part of the dialogue between user and vendor.

As a project manager and analyst, my heart is with Green. Indeed, helping users find a system that’s a best fit is why we started the Selector.

Marketplace Practicalities
Nevertheless, relying on a physician – vendor dialogue is, at best, limited and at worst unworkable. It won’t work for several reasons:

  • Nature of the Market. There’s not just one EHR market place where vendors contend for user dollars, there are several. The basic divide is between ambulatory and in patient types. In each of these there are many subdivisions depending on practice size and specialty. Though a vendor may place the same product name on its offerings in these areas, their structure, features and target groups differ greatly. What this means is that practices find themselves in small sellers’ markets and that they have little leverage for requesting mods.
  • Resources. Neither vendors nor practices have the resources needed to tailor each installation’s interface and workflow. Asking a vendor, under the best of circumstances, to change their product to suit a particular practice’s interface approach not only would be expensive, but also would create a support nightmare.
  • Cloud Computing. For vendors, putting their product in the cloud has the major advantage of supporting only one, live application. Supporting a variety of versions is something vendors want to avoid. Similarly, users don’t want to hear that a feature is available, but not to them.
  • More Chaos. Having each practice define usability could lead to no agreement on any basics leaving users even worse off. It’s bad enough now. For example as Ross Koppel points out, EHRs record blood pressure in dozens of different ways. Letting a thousand EHRs blossom, as it were, would make matters worse.

ONC as Facilitator Not Developer
If the vendor – buyer relationship won’t work, here’s a way the MU process could work. ONC would use an existing usability protocol and report on compliance.

Reluctance to put ONC in charge of usability standards is understandable. It’s no secret that the MU standards aren’t a hands down hit. All three MU stages have spawned much criticism. The criticism, however, is not that there are standards so much as individual ONC’s standards are too arcane, vague or difficult to meet. ONC doesn’t need to develop what already exists. The National Institutes of Standards and Technology usability protocols were openly developed, drawing from many sources. They are respected and are not seen as captured by any one faction. (See NISTIR 7804. And see EMRandEHR.com, June 14, 2012.)

As I’ve written elsewhere, NIST’s protocols aren’t perfect, but they give vendors and users a solid standard for measuring EHR usability. Using them, ONC could require that each vendor run a series of tests and compare the results to the NIST protocols. The tool to do this, TURF, already exists.

Rather than rate each product’s on a pass – fail basis, ONC would publish each product’s test results. Buyers could rate product against their needs. Vendors whose products tested poorly would have a strong incentive to change.

EHRs make sense in theory. They also need to work in practice, but don’t. The AMA –Rand study is a call for ONC to step up and takes a usability leadership role. Practice needs to match promise.

December 9, 2013 I Written By

When Carl Bergman’s not rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, 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.

How To Create Satisfied EMR Users

These days, we’re deluged with statistics on medical practices determined to show their EMR the door — but I’d like to believe that it’s possible for doctors and EMRs to have a happy marriage.

A few months ago, on question-and-answer site called Quora.com, a health IT expert named Mark Olschesky posted a nice list of factors which he believes are critical to a successful EMR/practice relationship. I thought they were worth sharing:

Doctors, clinic staff and administrators agree on business metrics and functions they want to improve with the EMR.

Some examples proposed by Olschesky:

· Right now I need to do manual chart reviews for research and I have to hire 3 staff to help me with this. I’d like to build forms so that I can do this automatically.
· It takes us 7 days to send follow-up communication to referring doctors. Can we speed this up to one day?
· I’d like to prove that I do a comprehensive visit so I can bill the proper amount of money for a visit.
· We would like to know every child that has a difficult airway and fire a warning every time we access their chart in the hospital so that everyone knows they need to prepare for a tricky intubation. This can save lives. 
· I do the same thing 50 times a day and I don’t want to do that anymore. Can you standardize the way that I do x thing 50 times a day?

The tech contact person needs to meet with clinicians regularly and get their feedback on what they want. 

Rather than simply coding up new features or tools, the  IT person needs to have clinicians check out the tools they are building before they go live with them in the system, he says. Some practices are loathe to take the time it takes to slowly and carefully build out, but they should grit their teeth and do it anyway. “It pays out at a major multiplier,”  Olschesky notes.

Practice leaders need to be absolutely clear about which organization-wide decisions are being made and how that plays out in how the system will be configured.

Rather than simply unveiling the system at go-live time, there should be an easy channel for clinicians to submit feedback and share what changes they think will be helpful to them, Olschesky says. Otherwise, groups may end up with doctors who are needlessly unhappy. While some unpleasant or unpopular features may still be necessary, due, say to regulatory requirements, none of these features should come as a surprise to users.

Practices should make sure that *plenty* of training opportunities are offered. 

Everyone in the practice should get enough training, specialized to their function, and everyone should be able to practice before the software is turned on. And everyone in the practice should give the system a test run with simulated  patients before go-live, he advises. Why? Well, aside from the obvious need to be oriented, there’s no such thing as a no-brainer EMR, he says. “This might make some UI/UX people cringe, but I’m going to say it: We can’t design an EMR solution that is totally obvious and requires no training and no practice,” he argues.

Getting the core EMR workflow to a level that’s comfortable to physicians is obviously of tremendous importance. But it’s not just a matter of getting physicians to a point where they can function. Practices will never be able to leverage the EMR to take care to the next level if they’re struggling to cope with the basics — and that’d be a real shame.

September 3, 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 FierceHealthcare.com 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.

MU Requirements Make a Decent EMR Suffer

If you’ve been missing the deep conversation we’re having in the “Develop Your Own EMR – You’re Still Crazy” thread, you’re missing some good conversation. Here’s one of the comments from Andrew Schechtman, M.D.

I’ve found the MU requirements can make an otherwise decent EMR suffer. For example, I previously used a web-based EMR that implemented an allergy documentation component that met MU requirements but was impossible to use in real-world clinical care. It didn’t allow one to enter a class of drugs (“I’m allergic to sulfas”) only specific agents. It didn’t allow an allergy entry without specifying the type of reaction. As any practicing doc knows, a good chunk of allergies come in as “I don’t know what reaction but my mom told me I’ve been allergic since I was a kid.” It met MU requirements but it was truly unusable. It continued in this unusable state for more than a year. I think it’s fixed now although I no longer use that product.

I’ve seen this from EHR vendors many times I’ve done demos. I’ll ask why something is there and then I’ll realize that it’s to satisfy meaningful use. I’ve often said something very similar about the healthcare billing requirements. EMR software could be so beautiful if it weren’t for insane healthcare billing and other government regulations like meaningful use.

I realize that it’s kind of water under a bridge at this point. Meaningful use is here to stay and the EHR incentive money is too tasty for most doctors and hospitals to ignore. However, I think the meaningful use requirements will eventually create an amazing opportunity for disruption. It will take a number of years for the billions of dollars of EHR incentive money to be spent. Plus, I think we’ll need some sort of healthcare collapse, possibly similar to the real estate collapse, to awaken people to the insane healthcare reimbursement. Both of those could create a tremendous opportunity for an entrepreneur to do something amazing for healthcare.

July 22, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com 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: InfluentialNetworks.com and Physia.com, 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.

Healthcare vs Sickcare, MU Undermines EHR Usability, and Kaiser Monkey Game


This might seem a little self serving since I sent this tweet in reply to Georg Margelis’ comment. It’s a really good question though and one I’ve been starting to think about recently. I’ve often heard that the really sick people are the ones that cost healthcare so much money. My question is whether keeping them healthy just delays the costs or whether keeping them healthy actually costs less money long term.


This is such an important topic. I’ve been commenting more and more on this subject. I’ve wondered if a usable EHR can be created that satisfies MU. I imagine it depends on how you define usable.


This is a pretty cool Monkey game from Kaiser. Although, the real value in this article is better understanding some of the approaches that Kaiser is taking to healthcare. So many people salivate over working with Kaiser. It’s good to understand what they are and aren’t looking for if you’re looking for that relationship.

July 15, 2013 I Written By

John Lynn is the Founder of the HealthcareScene.com 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: InfluentialNetworks.com and Physia.com, 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.