Business v. clinical computing: Workarounds to Barcode Medication Administration Systems

I recently attended the Government Health IT Conference & Exhibition 2008 in Washington. Many in the audience to the presentations were expressing puzzlement as to why HIT's diffusion was still relatively limited.

(As per the July 2008 statistics in the NEJM article "Electronic Health Records in Ambulatory Care - A National Survey of Physicians", NEJM 359:50-60, just four percent of physicians reported having an extensive, fully functional electronic-records system, and just thirteen percent reported having a basic system.)

Most at the conference seemed to gravitate towards blaming physicians in one form or another. I raised the issue that perhaps there are many other factors prevalent that are not well understood, and that more research was urgently needed. (To my surprise, the plenary session members agreed.)

In that regard, I find the JAMIA paper entitled "Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes and Threats to Patient Safety", Koppel, Wetterneck, Telles & Karsh, J Am Med Inform Assoc. 2008 Jul-Aug;15(4):408-23 quite fascinating. A free copy is at http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2442264/?tool=pubmed

The tables in the paper make apparent a tapestry of hidden and unexpected complexity in just one focused area of medical IT, barcoding for medications. I note that the tables are still far from exhaustive.

Yet, to attain even this non-exhaustive level of understanding in just one focused area, and to model the complexities, unpredictabilities and unexpected complications introduced by the seemingly straightforward solution of barcoding, prolonged, rigorous observational study by numerous domain experts was essential. It should be noted that none of the required expertise to do so was in information technology but in other fields such as sociology, medicine, informatics, and engineering.

These tables, especially table 3 (available at http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2442264/table/tbl3/) present in a compelling, easy to understand form, perhaps for the first time (especially by those outside of medicine) a substantiation of my belief that business computing, i.e., management information systems or MIS, and clinical computing are distinct subspecialties of computing. I believe the article and tables help illustrate why the two distinct computing subspecialties require different expertise and different leadership competencies.

The prevalent belief in MIS seems to be that medicine is another area of transactional business subject to conventional modeling by generalists, to be followed by "business process re-engineering" and traditional information systems development processes and methodologies.

However, the belief that one could employ conventional business-oriented "analysis" in the clinical world always seemed to me to be oversimplistic, overoptimistic, and in fact not infrequently harmful to medical practice as a result of the simplistic assumptions. It is a belief that does not perform well even in the conventional business world where significant cost overruns, project difficulties, and project failures are commonplace, let alone in the unforgiving environments of medicine.

The new article tends to puncture the belief (or perhaps more accurately, the article of faith) that clinical computing is just a subspecies of business computing.

Often heard in HIT circles is the mantra that HIT runs into problems because bad clinical processes are being automated, making bad processes simply "run faster." While it is also stated that these "processes" require revision before being automated, an issue almost never addressed in the health IT world is the appropriateness of the assumptions and analytic processes used to model those seemingly "bad processes" and to create the IT to support the better ones. Also not often discussed is dealing with the outcomes of the information technology "cure", such as in this article the need for workarounds.

Further complicating the overall HIT environment is an apparent belief that generalist MIS personnel must lead, manage and control the design, implementation and lifecycle of health IT. It's as if the HIT world believes a great symphony can be written by a thousand amateur musicians if they follow the finest of process and have a token, marginalized Beethoven or Mozart as an "internal consultant." In fact, it takes a Beethoven or perhaps a group of Beethovens and Mozarts in empowered leadership roles, facilitated (not led by) by the generalists, in order to produce excellent HIT.

The leap in recent years from a belief in clinical IT as a facilitative tool for medicine (which I believe was the original concept of the informatics pioneers) to a miraculous tool that will revolutionize medicine is therefore a huge leap of faith and logic that may be founded on seriously false assumptions.

In effect, health IT is supposed to treat medicine's ills. Yet, the industry through its own momentum and financial interests seems to shy away from diagnosing and treating health IT's ills. This leaves that task largely to so-called "mavericks" - those people who work outside rigid mental paradigms. Unfortunately, these people, while essential to thought innovation, can take a reputational hit for their efforts. This is demonstrated by some of the reactions to Koppel's 2005 paper on CPOE, especially by those with industry interests (e.g., Koppel's study was referred to as "disingenuous"), and reactions to some of my own writings on HIT difficulties, most recently when a well-known informatics writer with industry sponsorship recommended to one of my own [unknown to him - oops] graduate students that I not be used as a professional reference.

I also believe colorful shows of advanced clinical IT that cost millions of dollars to make function (usually in advanced academic medical centers) at trade shows further serve to increase forward HIT momentum at the expense of retrospective reflection. Expectations get set too high in the process, making non-clinicians forget that EMR supported healthcare transformation is 'too immature for credible estimates of cost or benefits' ( Electronic Medical Records and Health Care Transformation , Walker JM, Health Affairs, Sept/Oct 2005).

Perhaps we should not be surprised by suboptimal outcomes in such an overall environment.

As Koppel et al. conclude, "shortcomings in BCMAs [barcoding medical administration systems] design, implementation and workflow integration encourage workarounds. Integrating BCMAs within the real-world clinical workflows requires attention to use in situ to ensure safety features' correct use."

I believe that caveat holds true for all HIT, most importantly regarding HIT of a cognitive support function such as EMR, in distinction to a far simpler work process support nature as in the current example of BCMAs.

The new Koppel article sheds some light on the continuing need for a good deal of retrospective reflection on HIT before we fire the afterburners.

-- SS