Healthcare IT Sometimes Its Own Worst Enemy
Randy Thomas, IBM Business Consulting Services, Healthcare Thought Leadership
In healthcare information technology, we
use 3 and 4 letter acronyms with great abandon and no common
definition. EMR, RHIO, P4P. We invent new labels. We re-use old labels for new
ideas and don’t explain the difference. We break organic
healthcare processes into unnatural components and then apply these
labels. We focus on the parts and lose sight of what those parts are
supposed to do. And as a result we confuse the market.
What
am I talking about? Take CPOE – computerized physician order
entry. Or computerized provider order entry – take your pick.
There’s really no standard definition. CPOE, to me, is the means
for physicians (and other providers, depending on specific
state regulations) to enter orders into a computer both avoiding the
issue of illegible handwriting and gaining the advantage of automatic
alerts and reminders for things like patient allergies and
appropriate drug dosing. Only it seems that the alerts and reminders
bit is really clinical decision support (CDS). So for CPOE to be
most useful you need CPOE plus CDS.
Now, a logical person might
assume that the reason you enter an order is to communicate it to
someone else to carry out. But no, for CPOE+CDS to do this you need
order management (OM). That’s the bit that carries the legible,
clinically correct order to the lab or the pharmacy or imaging. It
now seems that all three of these bits together make up advanced
clinical order management (ACOM).
Really! All we’re trying to do is get an order from the head of a physician to someone who can carry it out as efficiently and effectively as possible, but to make sure you do that you need to know to buy all three parts! And you have to install them properly to get them to work together. And that’s just orders. Don’t get me started on documentation and results viewing!
When
you go to buy a car – you ask for a car. There’s a purpose you
have for buying the car, generally personal
transportation. You want to get from one point to another, sheltered
from the elements, reliably and comfortably. And you want your car
to run with the fuel that’s readily available, on roads that all vehicles can use, to park in places meant for any kind
of car to park in. You don’t buy a car and then find out you also
need to buy wheels and a fuel tank.
A “car” includes all the
things you need to use it for. You don’t
have to know all the parts that make a car work and ask for them
individually. You don’t have to carefully and painstakingly
“configure” the car once you buy it to get it home from the
dealer. In healthcare IT, however, we have these ever more granular
“parts” of functionality that are required to accomplish the
singular purpose of entering an order or reviewing a result or
documenting care. And we make the buyers figure out how to get all
the pieces and parts (of the same “car”) to work together
properly.
We need to provide these customers and clients with turnkey solutions, the kinds of integrated vehicles that will enable healthcare providers to get where they need to go.
That’s just the beginning, though. What would be really nice is if healthcare IT purchasers could buy new components of functionality that add to capabilities already in place. For example, using the car analogy again, you may have a 10 year old car that runs perfectly well (you’ve taken good care of it) but it doesn’t have air conditioning or a CD player, things that either weren’t available or you couldn’t afford when you first bought the car. You can go to the “after market”, however, and buy these components and have them added to your car. You don’t have to trade in your old car, spend a ton of money for a new one and have to get use to a whole new arrangement of levers and indicators just to get these two enhancements. That’s because the car and the air conditioner were designed to work together or “interoperate.” Not so in healthcare.
You may have a perfectly good pharmacy system. You may also have a perfectly good order entry system. They’ve been in place for years and work just fine. Now you’d like to add a more clinician-friendly way to enter orders that includes alerts and reminders. You’d really like to do this to help prevent medication errors. But you can’t just go to the “after market” and buy the new functionality and have it work with the systems you already own. These components weren’t designed to work together. No. You need to “rip and replace” both systems so that physicians can enter orders with the benefit of alerts and reminders and those orders can be communicated to the pharmacy system with enough information so the pharmacist can understand what alerts the physician saw and how s/he responded. This is expensive, wasteful and time consuming.
What we need is to be able to use information technology to support healthcare delivery. Caring for patients is important, challenging work. We should be trying to make the process of buying IT easier. Instead, we intimidate buyers with a fog of confusing acronyms and labels. We make it hard for customers to evaluate the technology that might best suit their needs. We make it unnecessarily expensive to adopt new technology because so much perfectly good old stuff needs to be thrown out to achieve incremental improvements. And as a result, buyers go through agonizingly long purchasing cycles in an effort to ensure their decisions are correct.
We need to stop the madness. Not only does our industry need technical and semantic standards that support interoperability, we need standard names and definitions for all the parts and pieces that make up systems. HL7 has started down this path with the Electronic Health Record (EHR) Functional Description, which is currently a Draft Standard for Trial Use (DSTU). This standard describes the various functions that together comprise an EHR. We need more efforts like this. Maybe not at the level of a standards development organization, but industry agreement on the names of things that is consistently applied. Vendors can each brand their products differently, but there should be a common understanding of EHR, CPOE, etc.
Finally, instead of coming up with new names, we need to actually achieve the promise of HIT. We need to help providers use IT to improve the efficiency and effectiveness of healthcare. If we do that, we can call the systems Fred. After all, “a rose by any other name would smell as sweet”.
Comments