Kaiser Health News (KHN) is a nonprofit news organization committed to in-depth coverage of health care policy and politics. KHN’s mission is to provide high-quality coverage of health policy issues and developments at the federal and state levels. In addition, KHN covers trends in the delivery of health care and in the marketplace.
KHN is an editorially-independent program of the Kaiser Family Foundation, a non-profit private operating foundation, based in Menlo Park, Calif., dedicated to producing and communicating the best possible analysis and information on health issues.
Mr. Hancock has quoted me regarding health IT in the past in his current role and when he was a reporter for the Baltimore Sun, for instance in the April 2012 article "Health insurers’ push to diversify raises ethical concerns" that appeared in the Washington Post as well, and the Nov. 2011 article "Advice to hospitals: Be careful what you bill for" in the Baltimore Sun.
Mr. Hancock wanted to get an understanding of me, the person. In doing so, I dug out some of my past technology "toys" to show him at the onset of the interview. Ironically, doing so reminded me of some irritating occurrences in the past that both inform present views, and served as early experiences in why health IT suffers the problems it does.
I will illustrate by showing some of the devices I presented to Mr. Hancock in order for him to better know my interests/knowledge of technology, and then presenting the unpleasant recollections that doing so brought on.
Bear with me for a few moments (and pictures).
I showed Mr. Hancock devices I'd built and/or used in teaching such as (click to enlarge):
|An infrared-sensing heart monitor I built in 1980 during a clerkship in biomedical engineering, Boston University Hospital, 1980|
|Inside the heart monitor. I etched and drilled the printed circuit boards myself.|
|A 3-transistor breadboard shortwave radio I built as a kid.|
|A somewhat more sophisticated radio kit. My Heathkit HW-101 ham radio transceiver, built myself over several months when I was a medical trainee. Also built its matching power supply box, not shown.|
|HW-101 innards, top view. Not exactly a simple device.|
|Inside the H8. I used this to teach computer and CPU architecture to Medical Informatics postdoctoral fellows at Yale School of Medicine. I did not, and do not believe healthcare IT leaders should be mere “appliance operators.”|
|My TRS-80 Model I running VTOS 4.0, a pre-IBM PC precursor to LDOS 5 and TRSDOS 6. All were far superior to MS-DOS of any flavor in my opinion.|
|TRS-80 Model I about to undergo repair by me.|
As I mentioned before the pictures, unpacking from their storage boxes and showing this personal technology brought out numerous formative memories, and not always good ones, from my CMIO (Chief Medical Informatics Officer) days.
Seeing all this, it may be easier to imagine why, as a CMIO in the mid 1990's I was offended when patronized by hospital IT personnel about how an information system in an invasive cardiology cathlab, a critical care area, could not be moved from unstable Windows 3.1 to Windows NT to prevent frequent crashes and data loss because “Windows NT needed RAID disk arrays” and other B.S., and also by similar personnel patronizing me on my serious concerns about ICU patients put at risk of infection by improper hardware for a biohazard-prone environment. (See http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=Cardiology%20story and http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=clinical%20computing%20problems%20in%20ICU.)
I was further reminded about how I was alarmed by the selfsame hospital IT "experts", lacking healthcare and medical informatics knowledge and experience, simply ignoring my counsel, as if medicine was a harmless parlor game to be played, winner take all. And likewise regarding hospital senior management who's hired me in the first place - at least one of whom expressed to me more concern for the career advancement of the IT staff than for patient safety.
The latter ICU incident, in fact, directly led to my starting to write about health IT issues on the Web in 1998. Sadly, my colleagues, as well as former students and mentees, tell me little has changed.
That type of territorial, political behavior might perhaps be more appropriate (or at least hardly harmful) in a nail salon or pizza parlor, but not in an ICU or cardiac cath lab.
Yet today's health IT domain is rife with leadership by health IT amateurs** [see note below] who patronize, bully and play nasty politics with healthcare informatics-educated clinicians and specialists, and accuse clinicians of being "Luddites" for resisting bad health IT pushed on them by hyperenthusiasts (Ddulites) who ignore the downsides.
Good Health IT ("GHIT") is defined as IT that provides a good user experience, enhances cognitive function, puts essential information as effortlessly as possible into the physician’s hands, keeps eHealthinformation secure, protects patient privacy and facilitates better practice of medicine and better outcomes.
Bad Health IT ("BHIT") is defined as IT that is ill-suited to purpose, hard to use, unreliable, loses data or provides incorrect data, causes cognitive overload, slows rather than facilitates users, lacks appropriate alerts, creates the need for hypervigilance (i.e., towards avoiding IT-related mishaps) that increases stress, is lacking in security, compromises patient privacy or otherwise demonstrates suboptimal design and/or implementation.
What is lost in these dysfunctional dynamics is that the true "customer" who suffers is the patient. Patients come to the hospital sick and with expectations that the personnel there will put the patients' interests first. If they are injured or leave in a pine box, they care little about whose political empires were threatened by internecine and/or industry battles over IT.
Mr. Hancock's Kaiser Health News profile of me, if published, should prove interesting. It will probably mention my own relative's injury and death related to health IT, and may cite the Complaint itself, a public document.
I will link to it when it if and when it appears.
** (Amateur, used in the same sense that I am a radio amateur licensed by the government after a series of written exams, but not a professional telecommunications engineer, knowing I would not want to, nor should be allowed to, lead a mission critical telecommunications project.)