Home » News » Currently Reading:

Curbside Consult with Dr. Jayne 6/13/16

June 13, 2016 News 4 Comments

image

I spent 38 of the last 72 hours seeing patients. Even the full-time physicians in my practice don’t usually work that much in a short stretch, so I’m not surprised that I found it exhausting. Normally, I find our EHR tolerable, but there were times in the last several days where it was unbearable. I experienced instability like I haven’t experienced since being a beta client for another vendor several years ago. I seemed to find more errors in the physician workflow than my co-workers found in the support staff workflows, and I could feel my attention drifting because I was becoming increasingly annoyed.

At one point, I was managing multiple high-acuity patients when I encountered a string of error messages. The one above nearly put me over the edge. End users should never see error messages like the one above. It’s insulting to the users and, although I’m sure it might mean something to a developer, it doesn’t mean anything to a customer who is trying to care for patients. It’s enough to make one want to wish for even more federal regulations – but only if they require vendors to provide mechanisms for graceful error handling.

As an EHR user, I sometimes feel like I’m a research subject in an experiment that hasn’t been approved by any kind of institutional review board. Everyone thinks that Certified EHR Technology is going to make our world a better place but the jury is still out on whether it’s going to truly be effective. And while we as physicians are having to cope with arduous workflows as a result of the regulations, there are advancements that would really benefit us that remain unaddressed.

Over the last decade, I’ve accumulated a wish list of product “enhancements” that would benefit the people in the trenches. Years later, though, they’re mostly unaddressed:

  • The NCPDP standard for electronic prescribing limits the “SIG” or prescription instructions field to 140 characters. I’ve been told for years that this will be addressed in a future version of the SCRIPT standard, but it remains unaddressed in any production system I’ve ever used. Physicians who have tried to prescribe triptans or other medications that require unstructured SIGs know exactly what I’m talking about. I bet 140 characters made sense at some point, but it’s time for a change. If we can regulate the picklist selections available for marital status, certainly we can regulate this.
  • Standardized lab ordering mechanisms are lacking. One major national reference lab supports electronic directory of services (eDOS) formatting but another doesn’t. This leads to a hodge-podge of strategies for EHR vendors who are trying to manage multiple lab compendia. Some use third parties to try to keep it straight, and others push the work onto the clients. This can result in thousands of physician offices trying to stay in sync with their reference labs, often with a lot of manual work. If we can regulate the use of CPT for lab charges, certainly we can regulate this. (I have to admit that I got a kick out of this reference on eDOS that mentioned that “MU3 proposed rules are anticipated to be published in January 2014 with final rule anticipated to be published in summer 2014.)
  • Requirements for lab vendors and the way they deliver results is lacking. Although physicians are required to use LOINC codes for results to meet various quality measures requirements, there is no requirement that lab vendors send LOINC codes with their results. I’m working with a handful of clients right now who are having to do manual recoding to attach LOINC codes to their results, so that they don’t get dinged on their quality reports. If we can regulate the use of SNOMED, certainly we can regulate this.
  • Interoperability remains elusive. Even when systems communicate, the mechanisms used to reconcile data from disparate systems can be clunky at best and downright unsafe in certain situations. Although some vendors have robust algorithms to identify potential matches and bring data seamlessly into the patient chart, others deliver a greater cognitive load than I experienced in my third semester calculus class. If we can regulative giving lip service to usability through user-centered design, certainly we can make it a reality.

Unfortunately, my list is growing longer rather than getting shorter. We’re forced to gather loads of information that could be put to good use but isn’t. For example, we collect information on race, ethnicity, religious preference, language preference, sexual orientation, and more. In many cases, it’s not used to further clinical care. It would have been great to have a prompt to ask about religious fasting the other night when I was treating a patient with profound dehydration. Although it occurred to me to ask, it didn’t occur to my patient care technician or to the resident I was supervising.

My state doesn’t have a usable database for identifying potential abuse of controlled substances. That’s not a vendor problem but a failure by our legislators to ensure that what they legislated was actually delivered as promised. It’s sad, because I could benefit from that kind of technology every single day. Other states have had it for years but here I am, calling around to try to confirm my suspicions when I’m concerned about a patient.

I know the industry is going through growing pains. There is a tremendous amount of external pressure and we’re trying to use technology to solve the broader healthcare problem rather than addressing the root causes. We can’t expect that to be easy, and I’m hoping we’ll look back on these times someday and chuckle at our relative naivety. Of course, there’s always the chance we’ll look back on these times fondly, because things will have gotten worse. Let’s hope that doesn’t come to pass.

For now, I’d settle for some friendlier error messages. I’d take “I’m sorry Doctor, I’m afraid I can’t do that” rather than hearing about unhandled exceptions or missing widgets. What’s your most annoying error message? Email me.

Email Dr. Jayne



HIStalk Featured Sponsors

     

Currently there are "4 comments" on this Article:

  1. “For now, I’d settle for some friendlier error messages. ”

    That’s sort of like saying, patients should never see their own blood in their wounds. For now I’d settle for some less bloody bandages. Well, sometimes you can’t help it.

    You’re not expected to see that error message. If it were expected, you would get a friendlier message. However, not everything can be caught. That looks like a lower level error message, something in the framework. Although the condition that caused could have potentially have been caught, this message is an underlying issue that the developer did not foresee. For example, it could have been a customization that the clinical team put it, but they typoed some string. Or maybe it was some report that was supposed to gather some data, but it found no data, or it found too much data, etc. With enough effort all of these can be caught, but you’d be paying for it by having a much less flexible system (no customizations), that took a really long time to release (to QA all possible scenarios) so by the time it came out it was already 5 years out of date, and it cost 3 times as much as it does right now. Are you really sure that’s what you’re advocating? There are trade-offs to everything.

    Now if you see messages like this all day long, all the time, and nobody is doing anything about it, that’s a different story.

  2. “The NCPDP standard for electronic prescribing limits the “SIG” or prescription instructions field to 140 characters. I’ve been told for years that this will be addressed in a future version of the SCRIPT standard, but it remains unaddressed in any production system I’ve ever used. Physicians who have tried to prescribe triptans or other medications that require unstructured SIGs know exactly what I’m talking about. I bet 140 characters made sense at some point, but it’s time for a change. If we can regulate the picklist selections available for marital status, certainly we can regulate this.”

    The reason why this never got updated is that generally EMRs want to move towards discrete sigs (e.g. “take [2] every [4] [hours] [or PRN]”) instead of free-text (“take two before lunch and one after dinner, and if you are still experiencing pain take one, but no more than a total of 6 in a single 24 hour period without contacting me first”). It makes the data more consistent and standardized, making reporting easier. Unfortunately those obscure use cases like you mentioned fell to the wayside and regulatory focus is now on scheduled drug reporting or other reporting issues with medications.

  3. “You’re not expected to see that error message. If it were expected, you would get a friendlier message. However, not everything can be caught. That looks like a lower level error message, something in the framework. Although the condition that caused could have potentially have been caught, this message is an underlying issue that the developer did not foresee. For example, it could have been a customization that the clinical team put it, but they typoed some string. Or maybe it was some report that was supposed to gather some data, but it found no data, or it found too much data, etc. With enough effort all of these can be caught, but you’d be paying for it by having a much less flexible system (no customizations), that took a really long time to release (to QA all possible scenarios) so by the time it came out it was already 5 years out of date, and it cost 3 times as much as it does right now. Are you really sure that’s what you’re advocating? There are trade-offs to everything.”

    Seriously? End users shouldn’t expect their software to work without producing errors? Mind blown.

    I believe the health IT industry as a whole could use a good dose of software development professionalism. Also, from what I can tell, most of the EHR software I’ve seen is already 3 times as much as it should have cost, and is already 5 years out of date.

    Demand better and perhaps you’ll get it.

  4. The point isn’t that I saw an error or that I don’t expect that there may be errors in scenarios that couldn’t be tested easily. it’s the error itself that’s the problem. How hard is it to make every error message have a graceful introduction, and then give the gory details? “The system has encountered a problem, please see below for details.” That’s at least more respectful of the user.







Text Ads


RECENT COMMENTS

  1. I think Disingenuous is confused (or simply not aware of how it has been architected). How control of Epic is…

  2. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  3. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  4. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  5. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.