The following appeared a little while ago.
A Call for Intuitive EMRs
Scott Mace, for HealthLeaders Media , July 24, 2012
I've previously remarked that software can't do it all—resolve all antiquated workflows or figure out stumbling blocks in people and politics. Unfortunately, that's just what EMR software is about to be asked to do.
Software is a funny thing. Done well, it anticipates the needs of human beings, or other software, and responds in flexible, flowing harmony.
Done poorly, software epitomizes everything wrong with modern society: impersonal, inflexible, regimented, mundane, boring, even maddening.
Where does your electronic medical record software wind up on that spectrum? Chances are, it doesn't look so good in comparison to your searching experience on Google or your shopping experience on Amazon.
"We need the EMR that's going to intuitively know the way our physicians practice and know the difference—and not every time a physician wants a change, we get a call, and we say we'll take that to the team, and the team will analyze it, and then the team will take it to the programming team, and in about a month, we should have your change put in our system," says Pamela G. McNutt, senior vice president and CIO of Methodist Health System in Dallas, Tex.
Software is a funny thing. Done well, it anticipates the needs of human beings, or other software, and responds in flexible, flowing harmony.
Done poorly, software epitomizes everything wrong with modern society: impersonal, inflexible, regimented, mundane, boring, even maddening.
Where does your electronic medical record software wind up on that spectrum? Chances are, it doesn't look so good in comparison to your searching experience on Google or your shopping experience on Amazon.
"We need the EMR that's going to intuitively know the way our physicians practice and know the difference—and not every time a physician wants a change, we get a call, and we say we'll take that to the team, and the team will analyze it, and then the team will take it to the programming team, and in about a month, we should have your change put in our system," says Pamela G. McNutt, senior vice president and CIO of Methodist Health System in Dallas, Tex.
"'EMR 2.0,' as I call it has to be intuitive. It has to adapt to the physician workflow without an army of 200 people in IT behind it trying to change the code," McNutt says. "That is not a sustainable model for us to have that many people behind the scenes creating all these boxes and screens. It has to be intuitive but we're all busy dotting I's and crossing T's.
"Even the 'Cadillac' systems for physicians and hospitals are nowhere near EMR 2.0 that I envision for the future," she adds.
McNutt hopes for some "dark-horse" software from an as-yet unseen vendor, maybe from Europe or sitting in some incubator deep inside MIT, to leapfrog the capabilities of current systems. "I could make a fortune if I could figure out who this is that's going to do that," McNutt says with a laugh.
Unfortunately, software innovators—the Amazons and Googles—only come along once in a great while. Healthcare CIOs appear to be stuck living with our current generation of imperfect software.
Another option kicked around, even more unrealistically, is to hope that clinicians adopt some kind of standardized workflow. That would help software immensely, because today's software has been constructed with layer upon layer of options to accommodate different workflows. This complexity in turn adds to the complexity of the software, of training for the software, and of trying to keep the training for the software inside one human head once training is completed.
"Even the 'Cadillac' systems for physicians and hospitals are nowhere near EMR 2.0 that I envision for the future," she adds.
McNutt hopes for some "dark-horse" software from an as-yet unseen vendor, maybe from Europe or sitting in some incubator deep inside MIT, to leapfrog the capabilities of current systems. "I could make a fortune if I could figure out who this is that's going to do that," McNutt says with a laugh.
Unfortunately, software innovators—the Amazons and Googles—only come along once in a great while. Healthcare CIOs appear to be stuck living with our current generation of imperfect software.
Another option kicked around, even more unrealistically, is to hope that clinicians adopt some kind of standardized workflow. That would help software immensely, because today's software has been constructed with layer upon layer of options to accommodate different workflows. This complexity in turn adds to the complexity of the software, of training for the software, and of trying to keep the training for the software inside one human head once training is completed.
Lots more here:
I am quite sure I don’t know how to fix this problem - but I certainly know it needs to be fixed. Just consider the NEHRS if you want an example of the worst sort of “impersonal, inflexible, regimented, mundane, boring, even maddening” software.
One thing is certain - the Health IT Industry needs help from all sorts of experts from other domains to do better than what is typically delivered!
David.
6 comments:
The best option ... is for clinicians to agree on (consensus being the biggest hurdle)... map, and adopt a standardized workflow (linked to evidence of the best health outcomes as self-reported by patents), where each workflow is ideally suited to each distinct clinical environment... because the other option would lead to an unsustainable degree of complexity.
What a load of codswallop.
Software is not something that can "intuitively know" anything.
Software is that part of an information system that implements rules and procedures defined by one or more people.
If these rules and procedures cannot be defined completely, including how to deal with errors and exceptions, then the system behaviour will be unpredictable.
It may be OK for a shopping experience to be unpredictable but I, for one, don't want my health to be at the mercy of a system that hasn't been properly designed, tested and isn't predictable and safe.
IMHO, McNutt is unrealistic in her expectation that "some "dark-horse" software from an as-yet unseen vendor" is going to come up with a miracle that will solve all her health IT problems.
The killer (and it's not a pun) question in this environment is "who is responsible if something goes wrong?"
You cannot hold software that "intuitively knows" something that turns out to be in error responsible for the death or injury of a patient.
So who is responsible? The clinicians who helped specify the system? The developers? The vendor? The operators of the system? The users of the system? It's hard enough with a deterministic system it is impossible with a supposedly intuitive system.
There is a reason why it takes developers so long to construct and implement an IT system - many things can go wrong, and in the case of health systems, they can go wrong in very bad ways.
IMHO, McNutt should stop laughing and pull her head in. She is setting expectations that cannot be met. Politicians and managers who do not understand the reality of system development might think that such systems can be developed.
I suspect we have people with unrealistic expectations behind the NEHRS. The way they are pulling back from their own predictions and target suggest they are adjusting their own and our expectations. These days they seem to be operating in damage control mode.
It's like telling a child that a fire will burn them. They don't believe you until they have burnt themselves. Having children in charge of a national eHealth system is not a good idea. Unfortunately, they won't be the ones to get burnt, it's we taxpayers and patients who will suffer.
Chris Kerr said best option is for clinicians to agree, consensus being the biggest hurdle. !!!!!
That is one of MANY barriers to progress which must be overcome.
However, spending time and resources trying to get busy clinicians to agree, when they all work in different environments and have different preconceived ideas, is an exercise in complete futility and a waste of time, energy and resources.
So, let us accept that instead of getting clinicians to agree in a consensus we find another pathway to overcome the barrier to progress which demonstrates what can be done in a way where they want it because it works, because it helps and because their colleagues who are using it are one step ahead of them and they are envious.
Ahhh I want what doctor suchnsuch has - it's terrific.
Deploy what works then market it seductively, progressively enhance and upgrade along the way, and the barriers to progress will be overcome.
Anonymous said
"Deploy what works then market it seductively, progressively enhance and upgrade along the way, and the barriers to progress will be overcome."
Agreed.
It's a much better approach than the usual "big bang" approach favoured by government.
It's not a perfect approach - there will be a lot of difficulties, blind alleys and temporary (but small) mistakes.
But it's a bit like Churchill's observation on democracy:
"democracy is the worst form of government, except for all the others that have been tried from time to time"
I think one of the biggest problems is that we already have the MR - medical record - and the vendors come along and say " throw all that out and put in our eMR." We have the MR, so really we need to add the "e" to it. It can be done, and in incremental steps replicate the way clinicians work. this removes much of the adoption issue and leads to adaption of process over time.
ANON 8/03/2012 09:37:00 AM
' ... However, spending time and resources trying to get busy clinicians to agree, when they all work in different environments and have different preconceived ideas, is an exercise in complete futility and a waste of time, energy and resources. ... '
Before a clinician purchases a software package they consider if the package is a 'good fit' for their intended purpose.
After using it, they form an opinion about whether their expectations have been met, whether all their workflow needs have been met, or whether parts could be improved.
So the first step... which parts are user-friendly and which aren't, which parts work well and which don't, etc, and why... is the first basis for consensus, and from that point, agreement is sought for each subsequent change/improvement.
Steps to building something that will be user-friendly, valued, robust, worthwhile, and 'fit for purpose'.
Post a Comment