I am a computer programmer. I describe my job as trying to make EHR systems usable, a nearly impossible task. If the goal for CMS is an EHR ecosystem that providers and patients like, it needs to start over from scratch. Meaningful use drove EHR development. That was a huge mistake. EHR systems did need some guide lines, but meaningful use was not what was needed. Communication guide lines were needed. Those are much harder to spec and implement.

Part of what the government needs to implement is a secure patient identification matching system. That will take years to get correct. After the matching system is ready, data exchange can be started. Data exchange can be built on top of DICOM and HL7 with SNOMED coming a bit later. Sorry for the tech ramble. Bottom line, CMS needs to work on patient matching and then get out of the way.

What is the definition of " patient matching?"

The ability to match a patient from practice A to the same person from unrelated practice B.

Add my voice for adding current EHR systems onto the bonfire.

I say the next step should be to provide examples of fixable problems that EHR companies won't fix, to highlight them by public shaming.

So, I have one:

In Epic, there are pre-populated prescriptions. To be fair, I think it is GREAT that EHRs can make prescriptions that are not illegible. This helps decrease medical errors. No more confusion between Zantac and Xanax and the like

However, if one changes the duration of the prescription, the number of pills to be dispensed does not change
Example: I prescribe "Augmentin" as the generic but the patient has previously suffered antibiotic-associated diarrhea
So, I decide to prescribe for 7 days instead of the pre-populated 10
If I change the Sig from 1 PO BID x 10 days to 1 PO BID x 7 days the number of pills to be
dispensed does not automatically change from 20 to 14

So, at my latest "Epic optimization" session I brought this up to my friendly tech, with whom I am on good terms.
He promised to send this suggestion up the chain to Verona to Epic HQ

Then, to my disappointment, I was told that the "Willow" team that is in charge of matters pharmacy refused to make this change.

And people wonder why doctors hate certain aspects of the EHR?

If others have other examples, I say bring them on.
Let's engage in EHR shaming
Let's also get the Feds to remove their liability protections for EHR companies that they were given earlier in this decade
under the provisions of the HiTech act. Did you know that EHR manufacturers were spared the burden of civil liabliity
under this act in exchange for job creation? To be fair, unemployment was higher when the act was enacted, but the
extra jobs to be created were basically, medical scribes, which is to say, a source of increased fixed overhead costs upon
the practice of every office-based doctor or upon the expenses of every hospital system.

Just my 2 cents
Gary

I 100% agree with removing EHR liability protections. That a physician or pharmacist would have liability for an inaccurate prescription created by an EHR is ludicrous. And please, don't comment that it is my legal responsibility as a Pharmacist or Physician, when companies like EPIC or Cerner are free to endanger the public at will and with no recourse. I installed my first pharmacy operating system on a UNIX mini-computer 35 years ago. And yes, in those early days, sometimes calculations like your Augmentin example did occur. BUT, this kind of error was totally solved decades ago by vendors who were panicked at the thought they would be named in a class-action lawsuit. It is unconscionable that medical professionals should still be struggling with problems that were solved a quarter century ago but are today still rampant due to systems cobbled together through corporate "acquisitions" that employ thousands of complex data translation tables to make all the pieces appear "seamless". As PLC Fischer has noted - it needs to start over from scratch.

Sorry, but I agree that EHR systems and most Microsoft products DO deserve an F - along with our Congress. This entire disaster needs to be rebuilt from scratch starting by creating permanent, cradle to grave, patient identification. Next, data exchange systems need to to be defined exactly. An HL7 field containing thirty-two characters of free text results in completely useless shared information because no two people are on the same page with the definition - except that it is 32 characters (or less) long. And how many I.S. departments have the staff to continuously communicate with every entity requesting information so that data translation tables are up to date? Not many, I'd venture. I am not a computer programmer, just a retired pharmacist who has installed pharmacy software from all of the major vendors and played key roles in the installation of a number of EHR's. I have found that most pharmacy software used to be fairly well written and patient safe. But the government's rush to implement Electronic Health Records pretty much threw patient safety out the window. If a patient matching scheme is 99% accurate (and they are not) that leaves a significant number of people at risk because you are now relying on an exhausted, frustrated, admissions clerk, nurse, doctor, or pharmacist to catch that 1% error so a patient receives the right medications and has the correct surgery they came in for. After nearly 10 years of working with this EHR fiascos, I decided to retire early because I saw no solutions forthcoming from Congress, Medicare, FDA, or any other agencies. All EHR systems are costly, resource intensive, cobbled together at best, frustrating for users, and potentially fatal for a small, but real, number of patients. It will take trillions of dollars and decades to straighten this all out, if ever. And, by the way, the last usable version of Microsoft Excel was in Office 2003. Ever since the "ribbon bar" feature bloat has made it as useless as most EHR's.