A "wicked problem" describes a problem that is difficult or impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize. Moreover, because of complex interdependencies, the effort to solve one aspect of a wicked problem may reveal or create other problems.
In the current environment of irrational exuberance, healthcare IT has been presented as a ready-for-prime-time, "mouse click away from great healthcare", put-it-in-and-reap-the rewards technology. An example of this 'HIsTeria':
“We have the capacity to transform health with one thunderous click of a mouse after another,” said (former) HHS Secretary Michael Leavitt - 2005 HIMSS Summit
"Transform" healthcare via "one thunderous mouse click after another?" On an irrational hyper-ebullience having taken over in healthcare IT, I rest my case.
Thunderous computing! Oh my!Unfortunately, realizing the capabilities of healthcare IT is not simple. It is in fact devilishly complex. For instance, is CPOE a "typewriter for orders", as it's sometimes represented in this industry to de-emphasize its potential hazards?
Far from it.
In recent testimony submitted at the HIT Policy Committee, Adoption/Certification Workgroup of HHS on February 25, 2010, a meeting on HIT safety, Geisinger medical informaticist/CMIO James Walker, MD wrote (PDF) the following (emphases and red comments mine):
... In 2005, Geisinger was preparing for its first inpatient EHR implementation. Several months into the project, the project director informed the CIO and me that the EHR team’s business analysts were unable to map safe and effective workflows between the new order-entry system and our existing pharmacy system (provided by another vendor).
[As an aside, one might question why "business analysts" were attempting a clinical mapping such as this - ed.]
They and the project director believed that the only safe approach was to de-install the existing pharmacy system and replace it with the pharmacy system provided by the order-entry vendor—at a cost of several hundred thousand dollars and a nine months’ delay in the project.
Pharmacy’s management was pained by the need to remove what was indisputably the best pharmacy system on the market [yet, even so, it needed to be removed and replaced with something that may, or may not, be equivalent in safety, ease of use, customizability, lifecycle maintenance, etc. - ed.] (which they had used very effectively to improve safety and efficiency). Nevertheless, they agreed with the workflow analysis and supported the change. Executive leadership approved the change and we proceeded.
Two years later (2007), when I reported this experience to an EHR-safety conference, David Classen noted that the results of the Leapfrog CPOE test in 62 carefully studied hospitals confirmed that this hazard ... appears to be present regardless of which vendors’ products are used. (Classen, in press).
[The effects of the disruptions at those 62 carefully studied hospitals might likely increment the "tip of the iceberg" HIT-related injury/death figures cited at the same meeting by FDA official Dr. Jeffrey Shuren- ed.]
In other words, any organization that implements a CPOE system needs to throw away whatever IT system is being used in pharmacy, with all of the familiarity and experience of pharmacy staff, and safety improvements that software might have provided because interfacing the systems is (allegedly) impossible and/or impractical. Then, after a learning curve characterized by disruptions in service, it is hoped the new pharmacy system will provide similar benefits to the old, and that the CPOE itself will work well (and not do this).
This disruption, caused by software dependencies in a complex biomedical setting and perhaps other reasons (see below), certainly represents a complex interdependency, the "solution" to which creates new problems, such as:
- What if the new CPOE vendor-sourced pharmacy system is inferior to the old?
- What does the organization due if the single-source vendor folds, now causing orphaned software over two, not one, critical functions?
- What other software-to-software interdependencies and bottlenecks exist that are not easily remedied by interfaces? CPOE-diagnostic imaging (radiology)? CPOE-laboratory? CPOE-O.R.? CPOE-dietary? CPOE-bed control? And so forth for CPOE and other systems to be installed.
- What happens if the CPOE fails (as here)?
As to causation of the allegedly irremediable incompatibility between CPOE's and Pharmacy IT, Dr. Walker submitted the following testimony:
... hazards arise due to failures in health IT design, implementation, and maintenance. (While many of these failures are due to a lack of skill or vigilance, many more are due to the interactions of complex healthcare processes and the necessary complexity of IT systems capable of supporting those processes.)
While I await the aforementioned Classen in-press paper on 62 hospitals, I take a more saturnine view and would argue that most of the interfacing problems probably have more to do with "lack of skill and vigilance" as opposed to some "organic" problem in interfacing these systems.
My view is based on experience in the IT backwater of hospitals and HIT, where bureaucrats and IT personnel largely are working far outside their core competencies; where straightforward software adaptations in complex subspecialties can be completely and repeatedly bungled until appropriate expertise is leveraged; where expert advice may simply be ignored and worse; and other pathologies. (See more on ONC Director Blumenthal's call for correction of the healthcare IT skills problem at "ONC Defines a Strategy of Robust HIT Leadership".)
The CPOE interface difficulties may also be in part due to vendor strategies of closed and overly complex software and information architectures, and vendor unwillingness to assist in interfacing to "alien" pharmacy IT products through ominous cost structures and halfhearted attempts. These matters could be strategic business decisions in a highly competitive market. (The supposed incompatibilities might actually be another argument supporting open source in healthcare...)
-------
In either case regarding interface difficulties, i.e., human-based vs. "organic" IT issues, however, one can see that health IT is no easy "plug and play" affair.
There is no predetermined benefit nor ROI. The complexities and "wicked problem" nature of HIT argue that benefits and ROI will not come short term - and never if the technology and its mass implementation are treated as easily tractable, not experimental and "wicked."
Finally, CPOE a typewriter for orders? Perhaps, if this is the kind of typewriter being referred to:
Typewriter for Japanese language-- SS
For more on HIT challenges see "Contemporary Issues in Medical Informatics: Common Examples of Healthcare Information Technology Difficulties" - http://www.tinyurl.com/healthITfailure
