Bringing "Sanity" to CPOE

March 2, 2011  |  Category: Clinical Applications

Albert Einstein quipped (did Al really “quip”?) that the definition of insanity is “doing the same thing over and over again and expecting different results.”

For almost exactly 40 years, hospitals have been trying to shove computerized physician order entry (CPOE) down physicians’ throats, and for 40 years physician adoption has been abysmal. According to KLAS’s 2010 survey, less than one-sixth of U.S. hospitals are doing even nominal CPOE with commercial software, and less than six percent of hospitals have all their physicians engaged with their CPOE system.

So does taking the traditional approach to CPOE qualify as “insanity”?

One of the biggest reasons for the failure of CPOE to date is that it hasn’t been designed for physicians. It’s a classic case – though surely not the only case – of software designers ignoring the end user when developing a product. In fairness, CPOE is a particularly challenging application because there are many different users that rely on the software – physicians, nurses, lab techs, pharmacists, unit secretaries, etc. The real challenge is that most CPOE systems are modules of a hospital information system and for the most part force the vernacular and constructs of the hospital order processing infrastructure onto their physicians.

If the technology industry has learned anything from Apple Computer, it’s that designing for usability can pay enormous dividends. And so it will be for CPOE – but it will have to happen fast, because the clock already is ticking on the ARRA/HITECH timetable, even as Stage 2 requirements (and beyond) are still being hashed out.

Based on years of speaking with physicians about what they do and don’t like about technology, here’s what’s needed to make CPOE physician-friendly:

* Order sets and order terminology must reflect the way physicians practice medicine and describe orders – Everyone would agree that practicing evidence-based medicine is important. Unfortunately, the majority of the orders in an evidence-based order set aren’t evidence driven. Most CPOE systems force hospitals to gather their physicians and develop a single “consensus based” order set. Modern software can do better. Why not allow physicians to take an evidence-based order set and tailor the non-evidence-based components to their practice? If a physician always has to add an order to an order set, why not add it automatically? If a physician never orders 50 percent of the orders on the order set, why not hide them?
* CPOE must save physicians time – Going from paper to a CPOE system is change. Change is hard enough when the change benefits you (as we all know from our attempts at getting in shape, being better parents, etc.). However, changing in a way that doesn’t benefit you, doesn’t save you time, and simply frustrates you, is a non-starter – and explains some of the historical challenges of CPOE. “Gee, Doctor, if you get really good at this, it probably won’’t take you too much longer than it did on paper!” is not compelling. CPOE must save physicians time, and a meaningful amount of time. Period. As an added bonus, the very important clinical decision support must be implemented in a way that doesn’t drive physicians crazy and cause them to ignore/curse all CDS alerts and messages. If a message is meaningless or irrelevant even 50 percent of the time, it will be ignored.
* CPOE must support physicians who are responsible for their patients 24×7 and on the run – Computers are great when you have to sit down and work up a complex admission order. However, they become a hindrance when a physician has to sign into a computer in order to request a routine lab test or add a PRN Medication for a patient that is nauseated. They are not really an option for a physician that gets called by a nurse who needs an order for one of his/her patients. Making CPOE as easy to use on a mobile phone or tablet as the rest of the world uses e-mail on these devices, is critical to physician adoption and eliminating verbal orders.

And here are a couple of things hospitals need in a CPOE system to stop the insanity:

* CPOE should elegantly support hybrid paper/electronic processes (at least in the short term) – Going from zero percent CPOE to 100 percent CPOE in a day is crazy. A big bang approach is both difficult and dangerous. CPOE must work for hospitals as they transition from “all paper” to “all electronic” order entry. Hospitals need a practical way to immediately implement – or incrementally evolve toward – a full CPOE process from any starting point, and move at their own pace toward the goal of 100 percent adoption throughout the organization.
* CPOE should be decoupled from a hospital information system – Most CPOE systems that exist today are modules of a hospital information system. That means that when a hospital chooses the right system to run their hospital, they, by definition, have also chosen the system their physicians will have to use. Giving their physicians a new system means that they have to rip and replace most of the hospital IT infrastructure. That’s not just insanity, that’s crazy. Despite what the major HIT vendors would like the industry to believe, there is no magical reason why physicians have to enter orders in a system written by the same vendor that supplied the lab system, pharmacy system, radiology system, and nursing system in the hospital. It is 2011, after all. Maybe this made sense back in 1971 when the first CPOE system went live, but not today.

Incorporating these principals into the design of CPOE will result in software that is built from the physician’s perspective and that is amenable to hospitals. Inevitably this will lead to widespread voluntary adoption and sustained meaningful use of CPOE.

And what of CPOE solutions that aren’t physician-friendly? They will suffer the fate of most previous attempts to implement CPOE – at the cost of patient care and outcomes, and lost ARRA stimulus dollars. And they’ll perpetuate the insanity.

Paul Brient
Chief Executive Officer
Paul has more than 20 years of experience in healthcare information technology. Prior to PatientKeeper, Paul held senior executive-level positions at leading healthcare and consulting firms, such as McKesson, HPR, and The Boston Consulting Group. Paul began his healthcare IT career as the founder and president of BCS, an early physician office management software company.