Wednesday, December 12, 2007

Doctors are not the venture capitalists and R&D arm of Acme EMR Corporation (with apologies to Linda Lovelace)

We have now reached the point where clinicians are being pushed from every side - industry consortia, government, patients, etc. to adopt clinical IT, often at their own cost and risk. Even suggesting that clinical IT may not be all it is cut up to be can result in highly emotional and unhappy feedback from various circles. It seems to be like suggesting God does not exist to the Vatican.

It also seems never to have occurred to the pundits that doctors are not the venture capitalists and R&D/beta testing arm of the Acme Anvil EMR Corporation.

I am a strong proponent of good Electronic Medical Records and related clinical IT (CPOE, CDSS, etc.) as tools to facilitate an improved quality of healthcare. However, several caveats apply:

1. The keyword is "facilitate." It must never be forgotten that the key to good healthcare is smart, well-trained, well-rested, well-compensated experts who treat patients from a framework of peace of mind. Believing you can reliably get good healthcare -- from frazzled clinicians whose practice is a nightmare due to paperwork, frequent battles with payers over minutiae, perplexing EHR's with which they are (apologies to Linda Lovelace) deep-throated by overzealous hospital and IT executives, vendors and governmental agencies, threats of reimbursement cuts and lawsuits, etc. -- is the belief of a fool. Clinical IT does not work cybernetic miracles; and another rule of thumb is that "Computer + Quack ≠ Marcus Welby." (≠ is the symbol for "does not equal.)

2. Another keyword is "good." Health IT can only facilitate improved healthcare if it itself is good. It must be designed via the principles of (at the very least) resilience engineering at the forefront:

The term Resilience Engineering represents a new way of thinking about safety. Whereas conventional risk management approaches are based on hindsight and emphasise error tabulation and calculation of failure probabilities, Resilience Engineering looks for ways to enhance the ability of organisations to create processes that are robust yet flexible, to monitor and revise risk models, and to use resources proactively in the face of disruptions or ongoing production and economic pressures. In Resilience Engineering failures do not stand for a breakdown or malfunctioning of normal system functions, but rather represent the converse of the adaptations necessary to cope with the real world complexity. Individuals and organisations must always adjust their performance to the current conditions; and because resources and time are finite it is inevitable that such adjustments are approximate. Success has been ascribed to the ability of groups, individuals, and organisations to anticipate the changing shape of risk before damage occurs; failure is simply the temporary or permanent absence of that.

In that regard, committees led by unidisciplinary IT personnel, focus on process by "process babes", consensus, systems lifecycle, and other characteristics and methodologies of management information systems and "merchant computing" do not reliably produce good clinical IT. In fact, often the opposite is true.

The rigor that transformed medical education and practice into a more scientific endeavor, initiated by the Flexner Report of 1910, needs to be applied to clinical IT. I personally demand the same rigor of health IT developers and managers that citizens demand of their clinicians. Is that unreasonable, I ask?

3. Clinical IT must be "evidence-based." As in my posts here and here and at my website here, the evidence is not entirely rosey. (I would venture to say the negative indicators are even more concerning than the corresponding indictors for, say, a drug like VIOXX.)

I have noted something peculiar about the changing role of Medical Informaticists as well.

Things are moving backwards.

A decade ago I was sought out to help a large medical organization choose the EMR product(s) best-suited to their various departments, specialties, and culture(s), and then assist in the implementation, customization, and culture changes required for its use.

A decade later (i.e., now), I find myself sought out to help large medical organizations who've pre-selected EMR's, often with the major say residing outside the clinicians and using a "one vendor fits all" approach, to help shove the products down clinicians' throats by pursuasion or coercion if needed. The requirement to continue medical practice and be a part-time CMIO and "Director of Clinician Gag Reflex Suppression" may be, I believe, reflective of this new phenomenon.

I also wonder if the emergence of CCHIT, the Certification Commission for Healthcare Information Technology that "certifies" features of clinical IT products pre-flight-checklist style (good in concept) is having unexpected consequences, as the field of social informatics predicts of any new ICT (information & communications technology) 'revolution.'

Could CCHIT be further facilitating the groundswell in recent years of an "irrational exuberance" and loss of critical, evidence-based decision making by hospitals regarding EMR's? Could CCHIT "certification" be encouraging hospitals to (incorrectly) believe they can skip or skimp on the "selection and evaluation" phase and jump right to purchase, and then hire an informatics expert after the fact to "change the culture?" Although CCHIT does not guarantee overall quality, usability and ultimate success of any product (in a nutshell, CCHIT merely confirms the presence of features), this could explain the "backwards leap" in the CMIO role I've noticed recently.

Finally, I believe the following questions need to be asked, asked again, and asked again.

  • Does clinical IT fix the problems it is purported to fix? If not, why not?
  • Is it consistently designed and implemented utilizing the best practices known to experts in engineering, medical informatics, HCI, and other areas, and if not, why not? Are the methodologies employed the same as the methodologies used for merchant computing, and if so, why, and what is the evidence this is the best path forward?
  • Are its drawbacks, both potential and observed, discussed openly, thoroughly and critically? If not, why not?
  • Are those who raise these issues praised, or attacked (e.g., as in Ross Koppel's work on CPOE being called "disingenuous" in print). If they are not praised, why not? If they are attacked, what are the true interests and agendas of those engaged in the attack?

Sometimes it appears the health IT industry reverses the roles of enabler of healthcare and facilitator of healthcare. Ultimately, though, patients do not fall ill, and clinicians do not toil in hospitals, so that the IT industry can have great computers, comfortable careers and watershed profits.

-- SS

No comments: