Friday, April 17, 2009

Health IT Vendor Blames HIT Problems on Those Damn Doctors, Since HIT is Perfect, Like Mother and Apple Pie

Seen on the HisTALK blog:

http://histalk2.com/2009/04/16/news-41609/#comment-3996
In my experience with EMR implementations, the big reason they are unsuccessful is because as Pete Potomus says “Drs are busy people” [busy with patient care activities and responsibilities - ed.], they want it to be flexible enough to conform to their individual standards and the customer doesn’t take ownership of the process of implementation and customization to the individual physician needs. It’s not that many of the EMRs don’t have the flexibility - it’s that the medical profession is too “busy” to take the time to learn the application [sure, doctors have all the time in the world to learn how to use tools like this - ed.], take advantage of all the functionality available and standardize their practice. Like any new “instrument” used in the practice of medicine, EMR take a lot of work to learn, tailor to the individual practice and become efficient.

I cannot fathom the remarkable arrogance and insensitivity above to the turmoil most physicians now find themselves in, squeezed from all sides - political, financial, legal, regulatory - in trying to render patient care.

This commenter's profile links to a Health IT vendor, Informatics Corporation of America. I find the comment "Like any new 'instrument' used in the practice of medicine, EMR take a lot of work to learn, tailor to the individual practice and become efficient" quite interesting.

I find it of interest in that, unlike other new instruments used in the practice of medicine, Health IT is entirely unregulated, and the vendors unaccountable.

Also, why does it take so much work to learn? Why is that rarely asked by the pundits and those who make money from HIT? Could it be due to the poor user experience HIT too often presents?

HIT is also not as infinitely malleable as the writer suggests, especially in areas such as workflow customization, clinical content, cognitive support and other areas. Further, in may large HC organizations, bureaucracy often prevents full use of customization features even as they exist.

Doctors and other clinicians then suffer.

One wonders if this vendor has ever considered that physicians’ reluctance to “standardize their practices" [i.e., alter their practices to conform to the IT designer's beliefs about medicine - ed.] might in fact be the best stance relative to patient safety in 2009? Or do they have absolute faith in HIT?

One wonders if this vendor merely believes the National Research Council's report on widespread inadequacies of HIT (the highest scientific body in the land), including the recommendation that "in the long term, [HIT] success will depend upon accelerating interdisciplinary research in biomedical informatics, computer science, social science, and health care engineering [to improve HIT]" is merely senseless prattle?

There is a reason I write about a cross-occupational invasion, piracy if you will, of medicine by IT. Physicians and other clinicians are being taken hostage - they either comply with the IT industry's demands for compliance to the cesspool all too often created by health IT (and the demands of its enforcers, a.k.a. government in 2009), or else.

Health IT failure is, after all, entirely doctors' fault. Right?

Wrong.

This canard has to stop. Now.

I've heard it for years (since at least the mid 1990's), and I for one, am tired of hearing it.

Who are IT personnel of any stripe to be telling physicians what to do? What, exactly, are their qualifications to render such judgments? (When physicians and other clinicians hear this type of "advice" they should ask this question. Loudly.)

The problems with HIT are that HIT is largely experimental and often substandard or defective, its purveyors conflicted and arrogant. Worse, many have grown imperious due to physicians' learned helplessness and vendors' shielding from liability.

We complain about dishonesty, dangerous products and conflicts of interest in pharma? Health IT seems significantly worse.

Apparently, this HIT company has found solutions to all the problems in the corpus below:


Joint Commission: Sentinel Events Alert on HIT, Dec. 2008.

National Research Council report. Current Approaches to U.S. Healthcare Information Technology are Insufficient. Computational Technology for Effective Health Care: Immediate Steps and Strategic Directions, Jan. 2009

The National Programme for IT in the NHS: Progress since 2006,
Public Accounts Committee, January 2009. Summary points here.

Common Examples of Healthcare IT Difficulties (website). S. Silverstein, MD, Drexel University College of Information Science and Technology.

Health Care Information Technology Vendors' "Hold Harmless" Clause - Implications for Patients and Clinicians, Ross Koppel and David Kreda, Journal of the American Medical Association, 2009; 301(12):1276-1278

Finding a Cure: The Case for Regulation And Oversight of Electronic Health Records Systems, Hoffman and Podgurski, Harvard Journal of Law & Technology 2008 vol. 22, No. 1

Failure to Provide Clinicians Useful IT Systems: Opportunities to Leapfrog Current Technologies, Ball et al., Methods Inf Med 2008; 47: 4–7,

IT Vulnerabilities Highlighted by Errors, Malfunctions at Veterans’ Medical Centers, JAMA Mar. 4, 2009, p. 919-920.

Unexpected Increased Mortality After Implementation of a Commercially Sold Computerized Physician Order Entry System, Han et al., Pediatrics Vol. 116 No. 6 December 2005, pp. 1506-1512

Role of Computerized Physician Order Entry Systems in Facilitating Medication Errors. Ross Koppel, PhD, et al, Journal of the American Medical Association, 2005;293:1197-1203

Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes and Threats to Patient Safety, Koppel, Wetterneck, Telles & Karsh, JAMIA 2008;15:408-423

The Computer Will See You Now, New York Times, Armstrong-Coben, March 5, 2009,

Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop. Journal of the American Medical Informatics Association. Bonnie Kaplan and Kimberly D. Harris-Salamone (preprint, doi:10.1197/jamia.M2997)

Bad Health Informatics Can Kill. Working Group for Assessment of Health Information Systems of the European Federation for Medical Informatics (EFMI).

Electronic Health Record Use and the Quality of Ambulatory Care in the United States. Arch Intern Med. 2007;167:1400-1405

High Rates of Adverse Drug Events in a Highly Computerized Hospital, Nebeker at al., Arch Intern Med. 2005;165:1111-1116.

"Dutch nationwide EHR postponed: Are they in good company?", ICMCC.org, Jan. 24, 2009

Avoiding EMR meltdown.” About a third of practices that buy electronic medical records systems stop using them within a year, AMA News, Dec. 2006.

"The failure rates of EMR implementations are also consistently high at close to 50%", from Proceedings of the 11th International Symposium on Health Information Management Research – iSHIMR 2006

"Industry experts estimate that failure rates of Electronic Medical Record (EMR) implementations range from 50–80%.", from A Commonsense Approach to EMRs, July 2006

Adverse Effects of Information Technology in Healthcare. This knowledge center presents a collection of information on the adverse effects of information technology in its application to healthcare. It also references sources of information on information security, and related media reports.

Pessimism, Computer Failure, and Information Systems Development in the Public Sector. Shaun Goldfinch, University of Otago, New Zealand, Public Administration Review 67;5:917-929, Sept/Oct. 2007

-- SS

1 comment:

Anonymous said...

HIT vendors must have drunk the SAP kool-aid: You will do it our way and you will like it. Companies pretty much have to change their business processes and workflows to fit the software, rather than being able to tailor the software to fit the business' needs. It is said the meltdown in Hershey Chocolate's SAP system one Halloween a few years back came about because the installing vendor customized the product heavily - at the client's request - and was unable to upgrade, as a consequence. SAP: Inflexibility 'R Us.