Decision Support Systems, Part II

Dr Alper is Clinical Professor of Medicine, University of California, San Francisco, and Visiting Scholar, Hoover Institution, Stanford University, Calif.

Last month I analyzed the failure of Quick Medical Reference (QMR) to become a commercially successful computer diagnosis program. The characterization of 850 diseases and the relationships among them might have been displayed in an electronic spreadsheet that physicians could rapidly consult. But the prospect of combining the data with artificial intelligence to automate diagnosis was far more exhilarating to the developers of QMR than building a "simple" reference tool.

So instead of offering doctors a way to supplement our thinking with more information, a black box that was hard to use?or entirely trust?was the result. The grand vision of making diagnoses automatically in conjunction with an electronic medical record was never fulfilled either.

In my own practice I would have liked to have a way, preferably hand-held, to check out diagnostic hunches without having to consult textbooks or wordy online disease descriptions. I'd want a snapshot of the disease's cardinal features and a list of diagnostic competitors to consider. Also, a list of tests to cheaply and noninvasively rule out inappropriate diagnoses. Then, the most effective way to rule in the likeliest one.

These functions were built into QMR. Other, less powerful substitutes have appeared since then.

After QMR, I was reassigned by First Databank to put together a team to build a new toxicology product that could be smoothly integrated into the physician work flow. Existing poisoning manuals were reference texts, and not designed to do this. The project was really exciting. It was aimed primarily at emergency department and in-hospital use. A toxicology pharmacist, a team of "knowledge engineers," and several computer experts and I initially worked on constructing the electronic framework and user interface for FirstTox. We then began the laborious task of adding new knowledge and creating links to the company's other drug information products.

Everything from inorganic and organic chemicals, whether used commercially or in the household, to exotica like snakebites and exposure to rare plants was included, as well as hundreds of prescription drugs that had figured in overdose cases or were candidates for that role. The substance descriptions, both chemical and physical, pharmacology, toxicokinetics, forms and products in which the substances are found all had to be researched, referenced, and coded using ".xml" tagging. Clinical information followed?descriptions of the clinical syndromes resulting from either poisoning or ingestion or other exposure to toxins. Where possible, these syndromes (eg, cholinergic crisis in cases of organophosphate poisoning or exposure to some nerve gases) were grouped for purposes of identification and treatment.

We created decision trees for when to hospitalize patients and protocols for treatment, all of which could be brought up with a mouse click or two. Our group forged ahead, creating nearly 900 substance monographs. My own time was split between practice (80%) and the office at First Databank (20%) plus another 20% for them coming from "free" time.

FirstTox was designed to fit into existing hospital information systems and link with the company's other informational products, such as patient education monographs and pharmacy data. The totality provided in-depth decision support?a mother bringing a child to the emergency department could have the child evaluated for a potential Tylenol overdose, for example, with confirmation of the pill ingested, appropriate lab testing and clinical observation, and then a decision made concerning whether to remain in the emergency department, be hospitalized, or go home, in which case a patient education monograph on the appropriate use of Tylenol could be printed out, all under the aegis of FirstTox.

Alas, development was discontinued based on market considerations?actually a reconsideration of the product's potential market by new management. In corporate jargon, FirstTox was "hibernated," whereas QMR had been "sunsetted." Changing course, the company acquired another company named Zynx that specializes in producing order sets for in-hospital use that incorporate evidence-based medicine. I miss FirstTox, but with hospitals earning bonuses from Medicare and private insurers for standardizing care and promoting best practices, there was no contest. Business goes where the money is unless creative ways for making products pay for themselves (think Google) can be found.

My current project is also in decision support, this time as a consultant to the Veterans Administration (VA). For a change, I'm working with a group that has a limited and well-defined objective: to create a tool to assist primary care physicians in treating chronic pain with opioids. It will be integrated into the VA Vista electronic medical record system and produce reminders and advice within the physician's work flow.

The grant that funds the program was motivated by significant problems with chronic pain management. Some 50% of patients treated within the VA health system have chronic pain, and of these, 30% take opioids. Undertreatment, overtreatment, incorrect treatment, and drug diversion are all too frequent.

I was brought in to provide a practicing primary care physician perspective?a privilege for me and a step that I fear is too often skipped in the creation of electronic tools designed to help physicians. My experience has shown why this might easily occur. Clinicians and information technology people inhabit different worlds. In medicine, and particularly primary care, we function with a high level of uncertainty. We use our brains to create "scenarios" that facilitate pattern recognition. We mentally jump around a lot.

Pity the information technology gurus who have to deal with an instrument that is powerful but not smart?the computer. They work hard to learn best practices from experts in the field. But doctors are busy, and the nondoctors don't want to pester them. So the tendency is to oversimplify and to lean heavily on those elements that can be easily quantified. The specialists who are consulted also do not inhabit the world of the primary care physician, and advice is often couched in terms of ideals rather than what is achievable. Patients who are exceptions to the rules create problems of documentation and classification. (And yet a program that doesn't allow for exceptions will infuriate doctors, rightly so.)

Increasingly, we also see decision support systems that encompass multiple agendas. CPOE, or computerized physician order entry, for drugs in the hospital is a case in point. Fewer errors in prescribing is the stated goal. Yet to accomplish this, physicians must do more work and put in more time?an economic cost?while the hospital saves money because fewer pharmacy personnel are needed. The word "accountability" creeps in and has overtones of policing and targeting physicians depending on how it is applied.

The opioid decision support system (DSS) is no exception to the multiple agenda rule. Better analgesia, less drug diversion, cost-effective prescribing, better documentation and compliance with VA regulations and state law are all goals. Another is increased use of urinary drug screens to detect multi-drug users or patients who don't take (and may sell) their pills. Increased use of long- rather than short-acting opioids?current best practice for chronic pain?is also hoped for.

However, even desirable goals can conflict, create complicated situations, and require physician cooperation to implement. Programs can do this either by "seduction"?making it easier to do the right thing?or by coercion, in which case opposition can be anticipated. Unnecessary make-work, such as asking for clinical detail that is duplicative and not always needed, will undermine even the best DSS.

If finding the right balance seems easy to accomplish, it really isn't. Hopefully, our team will come up with an instrument that avoids the pitfalls and is a win?win all around, and may then be adopted more generally.

That would be terrific. But there is a whole universe of other medical problems still to be addressed. Will each one have its own DSS? I keep wondering just how many DSSs physicians and the health system can tolerate.

e-mail: philip.alper@ucsf.edu