I will be honest: I seemed to have no clue. I assumed that many physicians’ grumbling and complaining about EMR was simply pettiness on the part of a bunch of individuals who want to be in power and reject progress. I assumed they were having trouble because they had been oblivious to the true advantages of internet recordkeeping, instead focused on their little current requirements. 

My move to a different practice provided me the chance to replace my previous EMR (which had all of the flaws I would grow to despise) with fresh, more up-to-date software. I assumed that somebody like me should have no trouble learning and mastering a new EMR. After all, I am familiar with data format, organized and unorganized information, and interfaces such as MEDCIN, SNOMED, and HL-7. I am a card-carrying part of the EMR elite, for God’s sake! It should be simple to launch a new product. If you’re curious, I will include my qualifications at the conclusion of this page. 

Consider my surprise when I became perplexed and puzzled while attempting to understand this novel product. How could somebody who could claim a slew of product improvements as my individual recommendations have an issue with a different system? The response to this question reveals one of the most fundamental issues with EMR systems.

First, there’s the issue of different languages.

As I fought to understand my newfound system, it dawned on me that I was experiencing similar symptoms to someone studying a fresh language. I was a scholar who specialized in German, and suddenly I had to learn Japanese. Both of these are written and spoken coding systems that provide the same function: data transfer from one individual to the other. Some of those same fundamental components are used in both: subjects, objects, nouns, and verbs. Kids learn both languages, and thousands of individuals speak them. In many respects, though, they are diametrically opposed.

The explanation for my feelings is that EMR products are, at their foundation, computer programs. They are developed by engineers with the assistance of physicians (many of whom have left clinical practice to operate for the EMR firm). The project’s goal might be to help doctors, but its spirit is that of an engineer. So, far more than anything else, the character of the developer determines how data is stored, how medical data is organized, and where something may be located.

Strengths vs. Weaknesses is the second problem.

The goal of an EMR is to make it easier for health care providers to record their work and retrieve data promptly. The truth is that certain elements are more critical to one EMR maker than they are to another. Activities that were straightforward in my previous system (adding labs, creating messages with structured information, receiving a quick summary of a person’s profile) are now challenging in the current one. Other jobs, on the other hand, are considerably better handled by the new regime (auto-completion of lab data, management of referrals, interfacing with a patient portal, etc.).

I am shocked at just how many stages are required to do activities that my previous EMR vendor completed rapidly. Why would they make it so difficult for you? It all boils down to choices, and certain items acquire utmost importance for whatever cause (CCHIT, Meaningful Use, Moon Phase), while others are relegated to the “later” pile.

The system is the third issue

The primary cause EMR technologies are so challenging is because they are developed in the hothouse of a disordered and unpredictable healthcare system, not because of the character of the developers who create them or the clinicians who use them. There are a billion ICD-9 codes, which defies clinical logic, yet they exist, and any EMR system that wants to succeed must focus heavily on ICD-9 (and, shortly, ICD-10 — yippee). Usually, clinic records are not structured to provide the most acceptable diagnostic data in the most straightforward style; instead, they are written for correct billing, with a 10:1 ratio of worthless to crucial insight. The bulk of data keeps getting in the way of what is genuinely needed in most letters, like a modest present enclosed in a massive box of packaging paper. EMR systems are built to create a large amount of packaging substance.

The technology I picked performs a great job in the E/M office. Still, it does so at the expense of concealing essential data and de-emphasizing what is therapeutically relevant for the purpose of E/M codes or qualifying the practice for “meaningful use” funding. I don’t blame the system because we practitioners invest considerably more effort on E/M codes and “meaningful use” than we do on client treatment. One of the principal factors I left my previous practice was this.

EMR systems, in actuality, are more meant to fine-tune the payment platform than they are for patient safety. Since “Health Treatment” pertains to the financial system rather than genuine patient care, this is the case. My annoyance with my present EMR system is not that it doesn’t do its work effectively (it still does…I hope), but rather that it was developed in a world where the misery of becoming a supplier is suffocating the honor of becoming a doctor. In our system, clients aren’t as crucial as money; thus, EMR systems will prioritize those factors. Those who do not do so will fail.

As a result, I bend my head in humiliation to people I despised in the old days. I became proficient in using a complicated tool that enabled me to regulate our system’s lunacy. It appears that my skills and experience were somewhat limited.