The following narrative was written responding to a post of mine on LinkedIn describing some of the healthcare IT issues of EHR. It’s author is Dr. Edward Kim, Associate Director, Health Economics and Outcomes Research at Bristol-Myers Squibb, and it is used with his permission. I think it coincides nicely with the need for more chief medical information officers.
EHR is definitely much more complicated in execution than in concept. Major barriers not mentioned include how this affects the process of care. Current healthcare has innate workflows that evolved around paper charts. Current vendors sell to the C-suite decisionmakers who believe linear processes reflect the actual delivery and documentation of treatment.
Having rolled out and used several enterprise EHRs, I can understand the high failure rates. Our clinicians felt they were treating their terminals rather than their patients. I can’t say we were fully successful because, while utilization was high, the quality of documentation was spotty as people found ways to game the system.
Thoughts?
Pale Rhino Consulting 
I agree totally! I love this blog and this post! (Of course, as a CMIO myself, I know the struggle… It’s hard to explain WHAT a CMIO does, and WHY it helps implementation…)
Thanks for the great blog! 🙂
LikeLike
We have a CMIO and here is what he does for us…he reminds us that we are performing CLINICAL implementations not TECHNICAL implementations. Which means that I must keep workflow foremost in my mind as I gather requirements for the solution. Also, dare I say, I must even question the need for a solution. It may be that they don’t need what we are offering and that maybe we should leave well enough alone.
LikeLike
Thanks for adding the part about questioning the need for the solution, a part which is often overlooked. Another way to question the need has to do with questioning the workflow, not the solution. I’d wager there are dozens if not hundreds of workflows whose entire raison d’etre can be summarized with the phrase, “That’s the way we’ve always done it.” These are workflows that may be duplicative, offer no added value to the process, or have been automated and are no longer needed.
LikeLike
My first assignment as a fresh school administration software author was to automate some new state and federal reporting for discipline and weapons in schools. This had to be reported via EDI to the state department of education. So I dutifully took the state EDI handbook and coded up a page that encompassed all the information in the EDI definition, and proudly presented it to the school district discipline coordinator.
He looked at it and said, “No. This is the paper form we fill out. I want it to look just like this, three days from now for the first day of school.” He laid a piece of paper on my desk, and I stared at disaster.
Three days (and about 3 hours total sleep) later I turned in exactly what he had requested — an electronic copy of the exact form that teachers filled out for a discipline referral to the office. The rollout was successful and the program served its purpose for the next seven years until replaced with a fancy new Java GUI program running on PC’s.
LikeLike
Paul Roemer replied (in part)
“I’d wager there are dozens if not hundreds of workflows whose entire raison d’etre can be summarized with the phrase, “That’s the way we’ve always done it.”
I’d wager there’s never been a workflow or process in the history of mankind that just spontaneously “was there.” A response of “that’s the way we’ve always done it” is code-speak for “I [respondent] don’t know / can’t explain / am relatively new / don’t want to think about it” …. but whenever that workflow or process was created (perhaps by darwinian evolution of prior art), there were reasons for it, reasons that were perceived to be better at the time than alternatives.
Those reasons may or may not still make sense, or still be the best choice given changes in other workflows, data collections, technology, external requirements, etc …. but there were reasons, there was some need that the workflow or process in question solved well enough.
But the implicit idea that “That’s the way we’ve always done it” is something of a license for (arguably well-intentioned) intervenors to change existing workflows and processes willy-willy … without having bothered to fully understand all the downstream implications before beginning … is a big part of the explanation of why so many of these efforts generate unhappy feedback and ultimately fail to thrive.
““That’s the way we’ve always done it” simply means more study and info is needed before operating on the patient. (First do no harm?)
LikeLike