Neither of those sound like good news for Oracle Health. After the lofty proclamations of the last couple years. still…
Curbside Consult with Dr. Jayne 11/30/20
A recent study looked at the idea that including a patient’s headshot in the EHR could reduce order entry errors. Although providers typically place orders on the correct patient greater than 99.9% of the time, researchers wanted to address the remaining 0.1%. The study was performed in the emergency department at Brigham and Women’s Hospital over a two-year period. They concluded that “wrong patient” orders were 35% lower for those patients who had a photo in the EHR compared to those who didn’t.
Although I’m supportive of the concept, I’d like to offer my own shortlist of solutions for error reduction in the EHR. Unfortunately, all of these were scenarios I’ve encountered in the last few weeks seeing patients. For the ones that are specific to the EHR (as opposed to operations or staffing), I’m not sure if the issue is truly caused by the EHR or by my group’s implementation of it. Because they so tightly control access to the vendor’s documentation, I have no way of knowing.
Medication Order Entry
Formularies should be configured to only support appropriate routes of administration. For example, in my EHR, if I select a medication to be prescribed to a pharmacy, I’m limited to the routes that are appropriate for the drug. Eye drops only display “ophthalmic,” oral medications only display “oral,” skin creams display “topical,” etc. It’s physically impossible for me to accidentally tell a patient to take their amoxicillin tablet topically unless I personally type it in the free text notes to pharmacy box, and even then, the pharmacy is going to catch it. For our in-house medications, however, some of them have options that aren’t appropriate, such as an IV push route of administration for drugs that should never be administered that way. It’s easy to click the wrong button, but removing the button would make the error impossible.
Similarly, doses should be hard coded so you can’t goof them up. If the office protocol is to prescribe famotidine 20mg IV every single time and to never use a different dose, why are we presented with a free-text field where we have to hand type it every time? We also have an issue where the in-house prescribing screen has navigation issues. You can’t tab from field to field, but rather have to move your hand back and forth from the mouse to the keyboard, which increases the chances that you might accidentally type “30” or “10” rather than “20” in the field if you’re in a hurry.
Orders should also be linked to avoid errors of omission. For example, if I’m ordering a liter of normal saline for IV hydration, I shouldn’t also have to order an IV catheter. I guarantee no one is going to try to do a straight venous injection of saline – of course they’re going to use an IV catheter. The system should also default timed infusions where appropriate. If the practice requires all infusions to be administered for at least 31 minutes in order to play the CMS coding game, then why not default 31 rather than making each of us type it every time?
Discrete Data Fields Should Be Appropriately Discrete
I cringe every time I have to document vital signs in our EHR. Blood pressure is a single field and requires the user to type the “/” in the middle and has no limitation on the field size. If my tech is having a bad day, I can get things like “180/1000” and the system doesn’t bat an eye (although it does flag it in red, at least). Someone at the vendor must have missed the memo on usability and not having a color change be the only indicator of an alert, though, because there is no other flag on the screen.
Especially for something like a blood pressure that you might want to graph or trend, the numbers should be captured separately, and the fields should be limited to reduce the risk of nonsense data entry. We have similar issues with height fields that aren’t configured to block nonsense entries. If someone doesn’t notice there are separate fields for feet and inches, you end up with patients that are 67 feet tall rather than 5’7” or 67 inches. Don’t get me started on our lack of use of the metric system with pediatric patients, which is the gold standard trained at most academic medical centers.
Use Technology to Assign Diagnoses That Make Sense to Both Provider and Patient
I’m a huge fan of systems that map ICD codes to patient-friendly and clinician-friendly terminology. Patients don’t want to see “R42: Dizziness and giddiness” documented on their charts. They want to see “vertigo” or “dizziness” or “lightheadedness” as appropriate with the ICD code behind the scenes. This is a pretty straightforward example, but there are dozens of wild and wacky codes and descriptions out there. Physicians hate it and I’m sure other clinicians do too. Patients end up with the wrong diagnosis on the chart when the provider struggles to find the correct one. Kudos to the IT folks who installed “the good stuff” technology wise to prevent this issue.
Use Technology to Keep Up with the Times
My EHR still does not have patient instructions for COVID. It’s ridiculous at this point. I diagnosed my first patient eight and a half months ago.
Reduce or Eliminate the Need for Multi-tasking Behaviors
This isn’t an EHR issue per se, but it’s the root of many of the errors we see. Clinicians need to be supported by their organizations and not expected to see patient volumes that are unsafe. Looking back to the pre-COVID world, my organization placed constant pressure on us to make sure that more than 95% of our patients were treated and released in under an hour. Sometimes that meant having one provider trying to juggle care for up to 15 patients depending on the number of rooms at the clinic. This can only lead to disaster depending on the experience of the clinician and the acuity of the patients’ issues. All staffing is driven by dollar signs, however, regardless of where you work.
One good thing that has come out of the pandemic is that they’ve capped the number of patients that can be roomed at a time based on the number of support staff, which means I rarely manage more than six patients at a time. It’s been a godsend and I can’t help but think it’s helped reduce errors, but at times it can still be unrealistic, especially when the patients are really sick and have a lot of labs and tests to manage. I have no idea whether those caps will stay in place as the pandemic eases, but I’m hopeful.
What error reduction strategies has your organization employed, or what seems obvious but hasn’t yet been implemented? Leave a comment or email me.
Email Dr. Jayne.
I was intrigued by your statement of “Because they so tightly control access to the vendor’s documentation, I have no way of knowing”…why do you think this is?
Most of the suggestions you have to improve order management in the EHR are features available in current vendor products. Things such as only displaying medication routes appropriate to the med in question, handling systolic/diastolic BP measurements, preventing “absurd” data from being documented, converting between English and metric measurements, adding supportive orders such as IV infusion sets for IV-administered medications, providing patient-friendly diagnostic vocabularies, etc. are features I’ve seen in EHR systems for over 20 years. It’s possible that these features were not included in the original implementation, and most organizations tend to stay with their initial implementation configurations until pushed by users to optimize the system after some period of use. It might be worthwhile to have an outside consulting firm review the organization’s current EHR configuration and recommend optimization opportunities, then have the users prioritize these for implementation. But it seems that budget constraints are the biggest obstacle to making these adjustments, as in incurs analyst time, configuration and testing, and user training. As for the vendor’s documentation being off-limits to you, your status as a physician informaticist (and perhaps a signed NDA) should enable you to gain access to the EHR documentation, so that you can provide adequate guidance on optimization opportunities.
Stupid question: Why can’t you name an EHR when you talk about its flaws? Answer honestly.
Of the six EHRs I am familiar with, I have seen at least one or two of the problems described in each of them. Certainly hard linking of administration routes or validation of vital values are rare or clumsy at best. COVID-19 CDS doesn’t appear to be updated — the last I looked two systems were still asking if someone had overseas travel — which is at this stage almost a moot point.
But, Dr. Jayne may have a different answer
I would say that while I like the ‘human usable’ versions of ICD, there is a risk introduced there. When you have three, four, or five systems all presenting the same ‘thing’ there is a Venn of items that will fall outside of the defined package. So dictionary A has 99% of what dictionary B has, which has 99% of what dictionary C has… Additionally, there are errors in the translations that are frequent enough that I set up a crosswalk validation to demonstrate the problem. So using these ‘friendly’ values will introduce failure in interoperability exchanges. The same thing for Problems/Dx is true for Medications. This can be aggravated by irregular update failures and requiring the clinics to update manually or by script — (do you have the CVX for COVID yet? 207, 208, and 213 for the NS vaccine or the MVX for the vaccine manufacturers?
Great list. You’re spot on. These were the EXACT issues I was frustrated with Epic in the early-mid 2000s. After going to get certified and talking with other Epic clients, I begin to realize that the Epic allowed the hospital systems to configure these as they see fit.
BP and Height Limits – Simple config on the back end of the software that your local IT dept should configure so that anything outside of x standard deviations should have an real-time hard stop that says “1000” is not an acceptable value for this field. At Geisinger in the early 2004, I would find patients come in with a BMI of 1000 (mainly because some fat fingered the height to 54 inches versus 5ft4inches (it would have metric in parenthesis)…not a HUGE deal in outpatient setting BUT once I implemented Pediatrics…WOW…this could NOT happen …so it was refreshing to see the backend configs that allowed us to set parameters for height, BP, etc based on the age of the kid.
Diagnoses Assignment – God came in and created Intelligent Medical Objects (which is the backend feed into most EHR that allows once to type in “back pain” and get something more specific. Once again, this is DEPENDENT on ‘how good is your local teams’ as Users Experience, Design thinking, etc. I’ve found that many Epic clients are just understaffed to deal with the UX stuff. They have to get the diagnoses loaded in and hope that the docs ‘save their favorites’ or the ‘departments submit their ‘speed button’ list, etc.). In all honestly, Epic has created a lot of ‘fixes and patches’ that can are ‘plug and play’ (turbocharger, wizards, etc)…however, I’m still not seeing many orgs adopt them as they have SOOOO much other stuff going on – updates, patches, backend stuff, etc. The front-end usability (UX) seems to get pushed to the back.
Order Entry – Doses etc.
– 10000% percent agree. Amazon and Google , etc uses ‘cookies’ to serve up a better user experience to prevent me from having to re-type stuff and get the value faster (they can be creepy too). Epic has the ability to track your ‘most common orders’ and track your ‘favorites’ and have these appear first when you search for things. Here’s the rub… LOCAL COMPLIANT and RISK DEPARTMENTS get really weird when these enhancement are brought up (not sure why teams are even asking them anymore…just turn it on). The only technical limitations I can think of is the ‘tyranny of choice’ that Epic and many EHRs employ…. it’s buttons all over the place. The last 5-10 yrs it seems that they have begun to limit the ability for clients to adjust too much and stay a bit more standard re: the UI and UX…however this can come across as a bit paternalistic on Epic part so many clients continue to adjust and tweak to their local needs which adds variation and limits the ability of healthcare systems to compare notes and use best practices regarding a USER CENTRIC DESIGN.
Epic also has UX and UI teams that really work hard (not being a sycophant, but I’ve met them and see what they do and have participated in these Usability Labs in Verona)! However, once all the testing and UX design s done, it’s then ‘shipped’ to the clients…however, clients/hospitals can decide that ‘wow…this is nice, but we only want A and D…our docs don’t want A-B-C-D (which was user tested)”…well there goes all UX wins…unless the local clients have the same expertise (which very few , if any actually do).
Long rants, but just saying….tech is tech…it’s ones and zeros and buttons can be moved and synonyms easily added on the backend to make looking for a 2D Echo a LOT easier.
I’ve written articles and presented on this stuff for the past 17 years. Here’s one that was particularly highly valued on HisTalk in 2019 – https://histalk2.com/2019/03/13/readers-write-to-douse-the-flames-of-physician-burnout-target-the-four-biggest-time-wasters-in-the-ehr/ ! GIST: Unless healthcare systems prioritize this area of EHR optimization by adding resources or getting external expertise to help, I’m afraid there will continue to be more features added and less usage #MyTwoCents #RantOver #StaySafe #MasksOn 🙂 – Dave
Non EMR user here, but isn’t the answer cloud-based systems, non configurable by locals?
The short answer to this question is to “just say no”. Cloud offers nothing that solves these problems that can’t be done by any other hosted or on prem system. Not saying that there aren’t advantages to each of those systems but those advantages/disadvantages have nothing to do with the problems described. And, unless the solution has been designed in “the” cloud, and more realistically for “A” cloud then a lift and shift is a recipe for failure.
And, if the belief is that locking a system down is the solution then you will have an EMR that is suitable for maybe 20% of EMR users. Thinking about it more, it may be less than 20% but I doubt it would be more.
EMR builder here. I would say most if not all of the problems listed above are solvable by a competent build team.