TECH: More on CPOE

Typepad (the hosting service I use) was down on Friday, giving THCB an involuntary day off. Here was my FierceHealthcare editorial on Friday. You can use this as a continuation of the discussion from last week:

There is little doubt that the big story in health IT circles continues to be
the CPOE study in Pediatrics which found an alarming increase in
mortality rates at Children’s Hospital of Pittsburgh. Those conclusions
generated a fierce debate as to whether we need CPOE systems, and whether EMRs
can be adapted for critical patient care situations. Yesterday, leading patient
safety expert Bob Wachter likened the phase medicine is undergoing to one
similar to that in aviation in the middle of last century–from independent test
pilots to team players–as described in Tom Wolfe’s The Right Stuff.
Even though no pilot would go back to doing things the old way, it was not a
painless transition. What is clear is that the introduction of new technology
requires a detailed examination of virtually every care process, and in some
cases the benefits can only be realized if the process is changed to fit the
technology. That is a very complicated sell.

Categories: Uncategorized

Tagged as:

10 replies »

  1. Regarding Allan’s comments above:
    Thanks for clarifying the issues so eloquently
    I cannot agree with you more on the scary prospect of using the verbosity of clinical documentation to justify payments. It is being done however in the name of EMR in the Emergency rooms and offices all over the country!
    It is hard for computer programmers and system administrators to understand that the way doctors think is “not structured”. In fact, the outcomes would be terrible for an occasional patient who does not fit the algorithm . A way a computer analyzes information is very structured and generally algorithm driven. Even the so-called AI is very primitive in its analytical capability. This is why the computers used for making clinical diagnosis were discarded a while ago!
    In smaller practices with one or two physicians, using ANY of the current EMRs is a waste of time and resources.
    In a hospital system where there is complex multidepartment interaction, EMR with an integrated CPOE will be helpful, if it features an intelligible interface,not a myriad of pull-down menus. Programmers need to see how the doctors work and then design the user interface to fit the style of work. Authentication should be rigid and work in the background using RFID technology.If not, you will be wasting precious time “logging in and logging out” If the EMR/ CPOE does not reduce the drudgery of work,why would you expect me to use it without being paid for my time?
    Computers are just a means to an end. In medical practice it is often used to blindly CONTROL, ALTERNATE and even DELETE physiciansn from NETWORKS!

  2. > Perhaps it would be useful to have tighter
    > integration between developers and clinicians?
    Sure. But there’s a whole essay in here, and I’m sure somebody else has already written it. Maybe I’ll look around a little and see what I can find.

  3. If I may add a few comments to the discussion as a practicing primary care physician, using an enterprise EHR, with an IT background:
    The structure of clinic notes can be customized to user preference if the end user has the expertise and if the program supports such modifications. The issues that hang up providers I’ve talked with are that either they lack the expertise or the program they selected for their practice does not support the option to customize. I have written a blog entry about putting more effort into educating residents on the components of an EHR so that in the future, they can be better consumers of available products and better equipped to modify/customize purchased solutions.
    Another consideration here for me is that while we are discussing billing and ergonomics, we may be getting away from what defines the need of a health record in the first place: our patients. Patient outcomes should be one of major foci in EHR development. The lit I have seen suggests that the implementation of a clinical decision support system (CDSS) may help improve the quality of care. This makes intuitive sense in that in a busy clinic appointment, a system that “double checks” labs and interactions, and is tied to the CPOE module may prevent an error. It may also make the the pysician more efficient. An example that comes to mind is the diabetic patient taking Metformin, which has an upper limit defined safe renal function for use. The ordering physician using a system with CPOE with a diabetic order set that includes Metformin may not check the renal function before putting the order through (say for example he or she is asked to put a refill through between patients). A system with a CDSS designed to cross reference labs might alert the physician prior to prescribing. I agree that healthcare is business and billing/reimbursement sustains in part, one’s ability to stay in business. However, if we can prevent errors, improve outcomes, especially in some of our most care intensive patients (diabetics) through enhanced data tracking abilty, we should take advantage of it.
    While I don;t think that all EHRs on the market are terrible, I would like to see more: flexibility, creativity, support, cost efficiency and inter-operability in EHR products. With the advent of AES, I think that wireless may have renewed applicability in the approriate setting. We need better communication between the clinical staff and IT within the industry and hospitals. I was at the Health Information Systems Society (HIMSS) convention last year and I asked a number of vendors whether they had any practicing clinician input to product development. Many of them said that they did not. Perhaps it would be useful to have tighter integration between developers and clinicians?

  4. Allan — they’re NOT standardized at all! Different physicians will use different terminology to describe the exact same disease or condition. Slee doesn’t want to impose a standardized terminology on the physicians because he sees that as information loss. He leaves it up to the natural language parser to build a representation using a standardized vocabulary of the “original” clinical record. He has some criticisms of SNOMED, but for the time being it is apparently the best thing we have, and for clinical purposes beats ICD-9 and (certainly) DRG.
    Matt — I also think auto-translation is a scary prospect for providers, but I’d be interested in hearing why you think it is scary for them…

  5. I think that auto-translation of clinical notes into billing records is a scary prospect for many providers. It’s no coincidence that the billing and clinical data are two separate worlds…

  6. Allan writes:
    > A care-focused EMR/CPOE system will feed the E/B
    > process, but is not a derivative of that process.
    This is one of Virgil Slee’s big points: there is a “clinical process” that goes on in human and medical terms, and we need a couple of different abstractions of it for the two big purposes: getting paid, and medical management & research. He thinks an ideal system preserves EVERYTHING a doctor takes note of and does, and produces the required abstractions from that. When the technology that produces the clinical abstractions improves, the original notes could be re-abstracted to encode more information or make better distinctions. This could also be done to study likely impacts of changes is payment rules too.
    It might be a pipe-dream, but there is at least one company parsing clinical notes with a natural language engine for coding purposes. They claim they do coding for billing purposes as well as an expert does, and most coders aren’t experts, so there’s a net gain. This produces the billing abstraction, but there is no reason the same idea could not be applied to produce a clinical abstraction of the record if we can just decide how that’s different from the billing abstraction.

  7. Sorry, forgot to address this bit:
    “What is clear is that the introduction of new technology requires a detailed examination of virtually every care process, and in some cases the benefits can only be realized if the process is changed to fit the technology. That is a very complicated sell.”
    I take issue with the idea that “…process is changed to fit the technology.” It would be more accurate to say that “the full benefits of applying these technological tools to the care delivery process are only realized if the care process is broken down, made repeatable, and (hopefully) optimized, then has the proper technological support for the process built around it.” It is certainly true that an unstructured process will not be possible to reflect in a structured workflow model, so some structure is called for. However, I would hope that the systematization of the care delivery process alone would accrue benefits (in terms of process optimization) that would provide benefits.
    Don’t make the technology the tail that wags the dog. These processes need to be better– technology is just a tool used in that context.

  8. Back in the previous thread, Narayanachar S. Murali wrote:
    “The currently availabe EMRs are terrible. Absolute waste of time. Each practice needs to know its work flow and design the IT it needs. There is no one size fits all when it comes to EMR. ”
    I assume that he is talking about small-practice EMRs based on his comments later in his writing, and I’ll basically agree (without a lot of detailed knowledge of this particular marketplace in terms of the offerings). I’m guessing that the big issue for this market is that the vast majority of IT offerings are focused more on the eligibility/billing process than on the care delivery process.
    A little more explanation may be helpful: When I take a process-oriented look at care delivery, I see two separate processes that interact– an eligibility/ billing process and a care process. These two processes interact, but are probably best thought of as separate processes (this does idealize the payer/delivery relationship a great deal, but stick with me for a minute). The Eligibility/Billing (E/B) process kicks off when the patient enters the clinical setting, either by calling to set up an appointment or by physically entering the care setting. Initially, the E/B process is concerned with answering a relatively simple question: if this patient is treated here, are we likely to be paid for delivering the required services? If yes, then some parameters may be handed down to the “care process” (such as “only generic drugs are acceptable for this patient”), and the patient is handed off to the care process. The care process runs and completes, then hands the patient back off to the E/B process for collection purposes. The E/B process is fed by the care process and may generate an exception if the care process generates outcomes that are not accepted by the E/B process (e.g., brand name drugs rather than generics).
    Now back to his comments:
    “If you wan to collect data for clinical studies include key-words in your billing software’s miscallaneous column so that you can get the charts to be reviewed any time. I have bought, tried and discarded multiple EMRs. EMRs using pull-down menus are ill-suited for medical care. they are OK for structured data entry for procedures with repetitive data.”
    Looking at his comments, it seems clear to me what we are looking at here– an “EMR” system that is an E/B process management system. This is a crucial distinction and one that is not solved by slapping the tag “EMR” on what is essentially an E/B process management system. The tip off here is the mention of key words in the Miscellaneous column and the pull-down menu comment.
    A “true” EMR/CPOE system is focused on the care process and not the E/B process. This is what many actors want and are thinking of when they discuss EMR systems and quality improvement. A care-focused EMR/CPOE system will feed the E/B process, but is not a derivative of that process.
    The conflation of E/B systems with true EMR/CPOE systems is due to several historical issues that need to be at least understood in order to move forward.
    1) Revenue collection is a critical process in any business, and healthcare is a business. Collections issues in healthcare can be complex and require significant record keeping, the type of record keeping that modern computer systems can address well.
    2) The collections problem has historically been a major reason for the installation of computer systems in healthcare providers of all sizes. This means that computer systems that currently exist in care facilities are highly likely to be focused on the largely clerical collections function (aka the E/B process) and not on the higher-value care process.
    3) The fact that electronic billing records do exist and are usually the only easily accessed data source about patient care means that they are often used to study outcomes of the care process. This data, though, is only a proxy for real patient data from the care process– the data that a true EMR would provide.
    4) The fact that an E/B process support system exists leads to the idea that any new EMR/CPOE system should interact with the existing E/B system or even be a “subfunction” of the existing collections-focused system.
    5) Starting an EMR/CPOE effort based on an existing collections-focused system is going to force the care process to accommodate the embedded data structures and processes in the E/B system. This will lead to a non-optimal care model and supporting process. At the end of the day our goal is not to build better collections systems, but to provide higher-quality care with better patient outcomes.
    I know nothing about the CH / Pittsburgh study, so none of this should be seen as a comment on that situation specifically. An EMR/CPOE system that slows the delivery of time-critical therapies would fail a key test as to fitness of the system. However, the time sensitive therapy context may be unique enough that it should be excluded from the overall EMR/CPOE project, or addressed in a special manner. reading the abstract of the study, I do see that the pilot period was rather short– a red flag in my experience (chiefly with financial system implementations).
    I liked the allusion to The Right Stuff because there are a few things that should be remembered by those who read it. One is that the pilots hated the new systems (especially the ones on spacecraft), because they severely limited the pilot’s ability to act– in some cases completely removing the ability to act entirely from the pilot. This loss of control was loathed by the pilots, who were used to full control.