Is Your EHR Stupid?

Yes, I know it’s a bit of a salacious title, but I think it’s an important question. Although, the answer to the question is completely obvious. Yes, your EHR is stupid.

At least the current state of EHR software is a bunch of dumb data repositories of healthcare information. That’s not to say that EHR software today doesn’t have value. The current EHR software can have tremendous value as I’ve been highlighting in my EHR benefit series. Although, just because something is useful and beneficial, doesn’t make it smart and also doesn’t mean we’re anywhere near the potential benefits that EHR will provide.

It’s worth considering a quick look back at how we got to where we are in the EHR world. First, EHR’s (really EMR if we’re splitting hairs) were created to be big billing engines. Since that was their goal, they got really good at it. In fact, the ugly spew of information that we know as templated notes came out of this desire to meet billing requirements easily.

In the next stage of EHR’s history, we layered on EHR certification and meaningful use. That’s right, EHR vendors went from coding software to increase a doctor’s ability to bill to now creating software that meets a set of government regulatory requirements.

Considering this history, is it really any wonder why we’re having a discussion of the EHR backlash that we see happening today?

While many might think this is a doom and gloom perspective. I’m actually incredibly optimistic about the future of EHR and the impact for good it can have on healthcare. Why am I optimistic?

My optimism stems from a number of different areas. First, I have tremendous respect for the creativity of people. I’m certain that we as a people will come up with EHR solutions that benefit healthcare greatly. Second, I think the “stupid EHR” that we have today lay the groundwork for all of the future benefits that will come.

This second point is a very important one. Most of the time people look at innovative ideas and think that they just came out of no where. Instead, when you start to study innovation you realize that most of the very best innovations have come from a mixture of small changes that are put together in a way that no one could have conceived before. I think we’ll see this applied to the EHR world.

The best example of this is what the IBM Watson technology is doing in healthcare. It’s great that a technology like Watson can take in so much information. However, Watson wouldn’t be able to learn anything about healthcare if the data wasn’t in digital form. That’s right, the simple process of having medical knowledge available in electronic form is an essential building block for something as powerful as Watson. The same is true for Watson’s analysis of a patient’s chart. How could Watson analyze a patient if all of their patient information was stuck in an offline world? Each move into the electronic world facilitates the next layer of innovation.

Yes, your EHR is stupid, but that’s ok. Just wait until you see the creative ways entrepreneurs and innovators will take your stupid EHR and make it smart.

If you have examples of this, I’d love to see them. If you have ideas of how to make a smart EHR, I’d love to hear them.

About the author

John Lynn

John Lynn

John Lynn is the Founder of, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • Great question!

    I wrote a blog post about this question several years ago, from which I’ll adaptive this comment.

    Question: Do We Need Smarter Users or Smarter User Interfaces?

    Answer: Smarter User Interfaces.

    Consider the distinction between intuitable EMRs (EMRs that are “figure-outable” by their users) versus intuitive EMRs (EMRs that figure out their users and do something useful with that insight). Intuitable usability corresponds to what I call shallow usability. It’s the “surface” or skin of an EMR.

    In contrast, intuitive usability (used “correctly”) corresponds to what I call deep usability. It is about how all the components and processes deep down behind the user interface actively work together, to perceive user context and intentions, reason and problem solve, and then proactively anticipate user needs and wants. Deep usability is like having the hyper-competent operating room nurse handing you the right data review or order entry screen, with the right data and options, at the right moment in your workflow.

    To perceive, reason, and act (let alone learn) EMRs need at least a rudimentary “brain.” When many folks think of medical artificial intelligence, they think of medical expert systems or natural language processing systems (rule-based, connectionist, or statistical). However, the most practical candidate “brain” today, with which to improve usability by improving workflow, is the modern process-aware (and context-aware) business process management (BPM) engine (AKA workflow or process engine).

    Intuitive EMRs need to represent user goals and tasks and execute a loop of event perception, reasoning, and helpful action. BPM process definitions represent goals and tasks. During definition execution, goal and task states are tracked (available to start, started, completed, postponed, cancelled, referred, executed, etc) and used to coordinate system-to-system, user-to-system, system-to-user, and user-to-user activity.

    BPM engines “perceive” by reacting to not just user-initiated events, but potentially other environmental events as well, an example of complex event processing. For example, a patient entering or leaving a patient class or category, going on or off a clinical protocol or regime, moving into or out of compliance, measuring or needing to measure a clinical value, or a clinical value becoming controlled or not controlled, are all complex events that can and often should trigger automated workflow.

    Smart EHRs are adaptive, responsive, proactive, and capable of autonomous action.

    “Adaptive systems: these learn their user’s preferences and adjust accordingly….

    Responsive systems: these anticipate the user’s needs in a changing environment.

    Proactive systems: these are goal-oriented, capable of taking the initiative, rather than just reacting to the environment.

    Autonomous systems: these can act independently, without human intervention.”

    Learn, anticipate, goal-oriented, initiative, independent…none of these describe the behavior of today’s typical EMR towards its users. As a consequence physicians must compensate with a torrent of clicks (so-called “clickorrhea”) to push and pull these EMRs through what should be simple patient encounters.

    What “drives” this smart behavior? An executable process model. In older terminology, a workflow, or process, engine, executes a collection of workflow, or process, definitions, relying on user input and context (the who, what, why, when, where, and how) to select and control definition execution. If the engine encounters inputs for which there is no model, then fall back on general purpose adaptive case management techniques for tracking goals and tasks, making them visible and actionable by physician users. Traditional BPM technology automates the predictably routine. More recent adaptive case management supports dealing with unpredictable exceptions—the high value-added knowledge work that diagnoses and treats the complicated cases.

    Usability can’t be “added” to EMR. It has to inform and influence the very first design decisions. And there are no more fundamental early design decisions than what paradigm to adopt and platform to use.

    No matter how “intuitable,” EMRs without executable process models (necessary to perceive, reason, and act, and later systematically improve), cannot become fully active and helpful members of the patient care team. Wrong paradigm. Wrong platform.

    A truly smart EHR, on the other hand, has a brain, variously called a BPM, workflow, or process engine. This is the necessary platform for delivering context-aware intelligent user interfaces and user experience to the point of care. Right paradigm. Right platform.

    In the spirit of advice from my Speech teacher about effectively and efficiently beating dead horses (”Tell them what you’re going to tell them. Tell them. Tell them what you told them.”) …

    Question: Do We Need Smarter Users or Smarter User Interfaces?

    Answer: Smarter User Interfaces.

  • Interesting. There’s definitely some overlap between UI and smart EHRs. That will be a major challenge since I predict that most of the smart EHR innovations will come from non-EHR companies. How they integrate the innovation into the EHR interface will be a challenge.

  • Fantastic article John! EHRs have a long way to go before they truly deliver what healthcare needs from them. One key to achieving improved “EHR intelligence” is to have an architecture that supports that goal. Specifically these systems must be able to access and use big datasets that provide deep and wide data from large numbers of patients. This will enable them to gain new insights and apply them in useful ways that help clinicians. See my article on that topic here:

    Perhaps most importantly, EHRs will only really succeed when they adapt to the clinician’s workflow rather than forcing clinicians to adapt to the EHR’s workflow. Although many talk about using an EHR implementation as an opportunity to re-engineer better workflows, the real-world outcome is very often the opposite – workflows that slow the clinician. Many believe that EHR implementations fail because they “pave the paper cowpaths” by replicating “broken” paper-based workflows in software form. I believe EHRs more often fail because they “pave the EHR cowpaths,” forcing clinicians into inefficient workflows driven by the limitations and needs of the EHR. Check out this paper that discusses this issue at length:

    Looking forward to the ongoing discussion on these topics!

  • I’m definitely intrigued by the overlap between workflow, UI, and intelligence. It’s a tough balance and very few people are able to work across all of these areas.

  • You’re intrigued by the right thing! The workflow-usability connection, or in this case, disconnection, is at the technological heart of what’s wrong with many EHRs today. Most EHRs are, essentially, structured-document management systems. All the bits and pieces of the medical document are stored in rows and columns of databases. And this is fine, as far as it goes. However, without *also* structured workflows, amenable to execution by workflow engines (also called process engines or orchestration engines in today’s business process management suites), physicians are forced to become workflow engines themselves. That’s what all the clicking is, the clicking that they hate. It’s the navigation from screen-to-screen and the manual triggering of events that should really happen automatically, without requiring physician attention. Ironically, and I think somewhat cruelly, physicians are sometimes characterized as Luddites for resisting modern, more efficient, technology. This is wrong in two ways. First, the Luddites attacked automated looms (precursors to our modern digital computers since they executed programs stored on punched cards) because they were *too* efficient. They eliminated the need for human labor. In contrast to those automated looms, and most modern technology today, many EHRs actually create *more* work for physicians (and, unlike the Luddites, they don’t want it). So that particular aspect of the physician/Luddite analogy is completely wrong. Second, Luddites had nothing against modern technology. They were angry and frustrated with their working conditions, such as they were. That part of the analogy holds up. Much health technology, even while it improves healthcare for patients, isn’t improving the lives of physicians. Until this mismatch between the goals and consequences of EHR technology is addressed and resolved, we will continue to see finger-pointing about who and what is to blame for slow adoption of EHR technology. Speech recognition and natural language processing will be part of that resolution, but it won’t be all of it. That is going to require the embedding of more sophisticated workflow automation into more EHRs.

  • One aspect that is often over looked, too often we feel, is the patient experience. The patient experience in regards to their interaction with the system, not the EHR but the patient facing interface, the patient portal. Not only do EHR systems lack effective back-end User Interface (architecture for Physicians), but they also lack a positive and engaging User Experience design for the front-end user (the patient). Without Patient Engagement Physicians will struggle to meet Meaningful Use and will inherently be unhappy with their EHR systems. If EHR systems want to remain a closed loop system then they really need to do a better job in this arena. The patient perspective is always important in healthcare, now so more then ever. EHR systems have been designed, in the past and currently, without focus on the user experience, and their patient portal solutions have received even less attention to user experience.

    Here at Achieve Internet we are striving to develop solutions that focus on the Patient. A technology solution that engages the patient and keeps them coming back to a physician is a win for the whole system, but without the focus on a positive user experience, interface, interaction etc, that can not be possible.

  • Chuck,
    Interesting analysis. Do you know of examples where they are getting the EHR workflow right? Even if it’s not the whole EHR, are their examples where you’ve seen what you describe actually implemented well?

  • Right now the software and web development company I work for, Achieve Internet, is working to implement workflow automation into the Healthcare space. We are working with a major Health Insurance client now and building a custom portal (NDA agreement will not allow me to divulge any further info, sorry). We have also built a solution for a medical device provider, Dexcom Inc, ( that really simplified the process of re-ordering glucose monitoring systems by integrating with Dexcom’s Oracle legacy system and their customer’s health insurance information. Before our solution was implemented, customers had to call in and fill out paper work and fax signed documents back and forth, the process took about a month, but now customers can easily and securely re-order their devices in as little as five minutes, from a smartphone if they want!

    Sorry if that was too much self promotion but solutions similar to that as well as the solutions that have been used for years in the Publishing industry can be leveraged to help solve the workflow issues within the healthcare space.

  • Thanks John,

    I wouldn’t want to comment on any particular product positively or negatively. However, I’ll unilaterally interpret your question as an invitation to elaborate. (Which, you know, I’m always happy to do!)

    The single most essential characteristic of “workflow” is task sequence. What tasks? What sequence? Task sequence varies greatly across who’s performing the tasks, where the tasks are performed, how the tasks are performed, what the tasks are, and why they are being performed (that’s context, and context drives workflow). By and large, tasks correspond to screens, or subsections of screens, in EHRs. That said, screenless tasks exist. In fact, one way to make an EHR smarter is to turn screen tasks that require user interaction into screenless tasks happening automatically.

    But screenflow is a good place to start. Here, the user is the expert. He or she knows what they need to do to do their job and in what order. But, while the user knows best, they don’t know everything. That’s why flexible, user-customizable workflow is so important. Later, after they’ve used an EHR for a while, they need to be able to modify workflows without requiring a trip back to the Java or C# programmer. If that happens, it takes forever, it introduces bugs, the software needs to be redeployed, users need be retrained, etc.

    That is the saving grace of modern workflow technology, also called workflow management systems or business process management systems or suites. There’s a workflow engine executing process definitions (turning manual screen-oriented steps into screenless automatic steps). The process definitions can be examined graphically, much like a decision chart, and then edited by someone who isn’t a programmer. This human editor of workflow may be a clinical analyst, or maybe even an ambitious and precocious user, who, after all, knows their own workflow better than anyone else.

    Use the Litmus Test for Frozen Workflow. Ask to see a demo. Ask them to pull up some sort of editor and to edit a representation of that workflow. Ask to see the demo again. The workflow behavior should change in the way that one would predict, assuming there is a workflow engine to execute the just edited process definition.

    It’s tempting to imagine an alternate history of Meaningful Use, one in which MU features and functionality were implemented on structured-workflow management systems instead of human labor-intensive structured-document management systems. Many screens could be created and edited by non-programmers. Then the workflows could be edited and reedited until users were happy with them, instead of the situation now, in which is workflow is the biggest Meaningful Use complaint (my subjective impression, others may disagree).

    Speech recognition and natural language processing technology is a special workflow case. The advantage of this tech is not just that speaking is faster than clicking (not always true, by the way), but that SR/NLP tech typically relies on more sophisticated workflow technology to weave it into point-of-care workflow. Early on this had to be true because layers of workflow were required to catch and correct speech recognition errors. Now that SR is so good, this workflow technology uses context (the who-what-why-when-where-and-how of what users says or even, heaven forbid, types) to automatically drive workflows. It turns tasks that otherwise require human intervention into tasks executed automatically by a workflow engine. Right now, speech recognition and natural language processing is viewed an adjunct and value add-on to EHRs, to make them more usable and useful. However, in the not too distant future, as SR/NLP platforms add more-and-more EHR-like functionality, we’re going to seen some very interesting competition: “Don’t buy a clunky EHR when you can have a Meaningful Use certified SR/NLP smartphone that sings!”

    But speech/language/workflow tech isn’t the only game in town. Much of the attraction of smartphones and tablets to physicians is that they appear to have much simpler workflows than EHRs. Part of this comparison is an illusion, but part of it is becoming real too. There’s often a direct correspondence between context, app, and workflow. If you want to do one thing, quickly, and that app is on your home screen, and that app has a two or three-step non-branching workflow: fast and easy! However, these apps are “sandboxed” for security reasons, preventing them from easily sharing clinical context. So, while workflow within an app is simple, workflow across apps, in any attempt to comprehensively replicate EHR functionality, gets you right back to where you were, if not worse, with traditional EHRs, at least with respect to workflow usability.

    While limitations on secure sharing of clinical data and context across solo apps are being addressed by various cloud-based technologies and platforms, many of these systems also rely on (wait for it…) workflow engines in the cloud. At the recent HIMSS conference I saw some let-us-mobilize-your-legacy-application-without-much-programming-required vendors in the exhibit hall. I suspect that workflow engines play important roles in their Model-Driven Composition Environments (that’s a Gartner term for codeless, or nocode programming).

    So, regarding existing EHRs, apply the Litmus Test. Regarding the near future, language technology and workflow technology are traveling into healthcare along with the SMAC techs (Social, Mobile, Analytics, Cloud) in all kinds of interesting and promising ways.

    Anyway, sorry this is not the answer I think you hoped for, such as a list of EHRs with great workflow. There are some out there. Do a Google search of “workflow” and “EHR” or “EMR”. Check out some of the EHR tag lines. If they emphasis great workflow, well, maybe there’s a correlation with actually having great workflow. (But apply the Litmus Test of Frozen Workflow: trust but verify!)

    By the way, if I may put in a plug for my new blog…

    As you know (you’ve left comments, so I know you know!) I’ve had a blog called Electronic Health Record Workflow Management Systems at

    for years. I’m finding that I’m blogging more and more about other things besides workflow, such as social media, natural language processing, cloud, mobile, etc. Plus, both “EHR” and “Workflow Management Systems” are getting a bit long in the tooth. Evidence for the former includes recent articles and blog posts about an EHR backlash and physician revolt (your influential post below). Evidence for the latter is basically that the workflow management systems industry has rebranded itself the business process management industry.

    The Coming Physician EHR Revolt

    (some of your finer and most insightful writing)

    So I started a new blog called The Healthcare Business Process Management Systems Blog at …

    …to focus more sharply on BPM in healthcare. I’ll continue to blog at EHR WfMSs (to which I am attached) about a variety of stuff.

    Hope you don’t mind me mentioning the new blog here and I hope you’ll stop by time to time. I’ll tweet links to it from my @EHRworkflow Twitter account.

    Thank you John for managing such a great public forum for discussing and constructively debating the grand health IT issues of the day.



Click here to post a comment