The following material makes the reports of poor alignment of EHR's to clinical needs, clinician distraction, and the slowing of clinician productivity more understandable by laypeople.
The following are PDF's from a real healthcare organization, publicly accessible (at present), some with actual screen shots of the applications.
How about a 90-page guide simply for entering orders, incidentally grossly mislabeled as "Medical Informatics Physician Education Program" instead of "CPOE application training program" suggesting the authors do not know what Medical Informatics actually is - and also labeled as "Session 1":
- Managing Patient Care Using CPOE (1.2MB PDF)
Here's what it takes to simply discharge a patient:
- House Wide Discharge (Depart Process) training manual (1 MB PDF) - 30 page training manual
"Depart Process" is apparently a new buzzword. (Borrowed from the airline industry?) In the B.C. era (before computers), discharge required no 30 page training manual.
I find the introduction to the 30 page "Depart Process Training Manual" interesting:
Good News! The discharge process has been revised and will be a smoother, less complex process for all. The new process will be to use the House Wide Discharge (HWD) Process, (Depart) when discharging your inpatients.
"Less" complex? One can imagine what the "Depart Process" was like before this 30 page training manual.
Here's what it takes to enter or review a note:
- Electronic Documentation –Clinical Notes (12 MB PDF)
Holy complexity, Batman! Entering a clinical note used to involve opening a chart and applying pen to the right paper.
Here is what medical professionals have to contend with when even a minor change is made:
- Tab Changes in the Power Chart (150kb PDF)
Here's what happens if physicians don't complete their H&P's in 24 hours with the EHR system:
- Suspension (31kb PDF)
I especially find the introduction to this "H&P suspension" letter of interest:
You may remember earlier this year when we started immediate suspensions for H&Ps missing at 24 hours as outlined in our Rules and Regulations. Many of you were caught off guard by this and resented being called after you had already missed the deadline and were suspended [I'll bet - ed.].
We certainly heard your complaints [doctors are simply "complainers" - ed.] and stopped the immediate suspensions until we could create a better process. Since then we have been working on ways to achieve the goal of 100% H&Ps present within 24 hours. We have met repeatedly and received recommendations from HIM [Health Information Management a.k.a. Medical Records - ed.] directors, administration, and senior medical staff leaders. Final proposals have been approved by the Medical Executive Committee and are presented to you here.
Beginning January 4, 2010, we will again begin suspending at 24 hours if an H&P is not available on the chart. The stopwatch will start at the time of the admit order. We will make every ["every?" - ed.] effort to contact the physician as the 24 hour deadline grows near. For the few physicians who have had multiple late H&Ps this past year, you will be contacted separately and required to formulate an action plan to present to administration and senior leadership.
Repeatedly late H&Ps will trigger recommendation for a shortened reappointment. Additional measures have been proposed by senior leadership for adoption, if necessary. These include limiting service sizes, stopping all admissions for suspended physicians (not just elective admits) or required use of a nurse practitioner (for a charge) to complete the H&P. [In fact, perhaps physicians should be charging hospitals for their time in being forced to use IT such as this - ed.]
Mussolini could not have done better in getting the trains out on time. At least trains were not experimental technology. (I'd thought it was deplorable as an internal medicine intern in the early 1980's at the now-defunct Hospital of the Medical College of Pennsylvania when our penurious paychecks of about $300 per week were merely withheld if we had not completed our discharge summaries.)
I've commented in the past that physicians and other clinicians are now held hostage to needlessly complex and difficult to use health IT (see my eight part series on the HIT mission hostile user experience here). I don't see anything here to make me change my mind.
Needless to say, being a Medical Informaticist I am not against health IT: I am pro-health IT.
What I do oppose is bad health IT - ill conceived, poorly implemented, mission hostile HIT designed with little thought to, or willful ignorance of, real world side effects in the clinic, office and subspecialty area.
Health IT can be designed to be far better than most commercial HIT from major vendors is now, of which the above links show but one example. This requires, however, that HIT be viewed not as computer projects that involve clinicians, but as medical projects that involve computers.
From that view flows the need for a major shift in HIT power structures and an educational and certification process for IT personnel (such as recommended by the ONC director Dr. Blumenthal that I highlighted in the post "ONC Defines a Taxonomy of Robust Healthcare IT Leadership").
For sake of comparison, from the same hospital system as above, here's what physicians must go through to be found competent:
- Privilege Criteria Grid (120kb PDF)
Here's what IT personnel must currently go through to earn the privilege of designing the tools clinicians must use, and of working in healthcare settings:
The same symbol applies to oversight of such tools themselves by accepted biomedical regulators such as FDA who regulate drugs and tangible medical devices. As I have written before, HIT is a virtual medical device, but a medical device nonetheless. It is a device that by the admissions of its own producers is entirely capable of effecting major impacts on and alterations to clinical care, although the makers rarely admit to adverse impacts.
These discrepancies are astonishing.
-- SS
16 comments:
These devices impair physicians' ability to care for patients. They are toxic to the safe and effective administration of medical care. They should be removed from use.
Readers who agree with the perspective of SS should notify the FDA and your Congressman and Senators.
Demand a recall.
This quote comes from a doctor authored blog:
“My ED is like most others: there’s a plan for where computers go, and they get installed on the desks correctly. Unfortunately, there’s not a plan for all the wires, power strips, etc that are associated with these installations.
The wires, cables, power strips, etc, just wind up on the floor. They collect dust and then the area doesn’t get swept, let alone mopped (we’ve had dust bunny races under the counters). (I don’t blame housekeeping: they don’t want the blame for pulling out any wires, so they avoid them).”
The name has been withheld to protect the doctor. The post goes on to cover how the doctor used tie-wraps and strips to clean up the area and is now waiting for racks to place equipment on to further eliminate clutter.
If the computer people cannot keep a hospital clean, how can they then go on to proclaim the benefit of all this technology? There is a disconnect between those doing the work and those designing the work flow, it is not only tremendous, but dangerous at the most basic level.
We need to rethink the place of technology in hospitals and those who are promoting, and often designing, systems.
Steve Lucas
"Less" complex? One can imagine what the "Depart Process" was like before this 30 page training manual.
Having a 30 page manual does not mean a process is complex, it means the process is well documented.
Steve,
As a Director of Medical Informatics in a large U.S. hospital, I encountered endangerment of the very sickest of patients from information technology. ICU patients were being put at mortal risk via inappropriate, dust-laden, air-circulating, business class computers subject to bacterial colonization that were mounted on the ceilings above each ICU bed.
An ICU is a setting where one finds the most noxious and drug-resistant organisms, many airborne. These pathogens (e.g., MRSA, TB, and even worse) can spread from a sick patient, to the dust and contaminants inside the computer, then to the room’s next occupants via the PC’s internal air circulation fan. The PC’s were malfunctioning as well due to a system architecture inappropriate for mission critical settings, and keyboards and mice were unprotected from bacterial contamination. My advice on changes to more appropriate hardware and other measures to ensure patient safety were simply overruled by IT personnel.
That case among others led me to start my web site on HIT difficulties.
What else can I say?
-- SS
IT guy wrote:
"Having a 30 page manual does not mean a process is complex, it means the process is well documented."
This is a non sequitur.
To readers here, "IT guy", who I also believe is "Programmer" in the comment threads at HISTalk, also apparently lacks any medical credentials and is not qualified to opine on complexity in clinical affairs.
This is a non sequitur.
No, your article is a non sequitur. You claimed that the depart process is complex, but the only support you offered for that claim is that there is a 30 page manual. A 30 page manual means that the process is well documented, not that it is complex.
is not qualified to opine on complexity in clinical affairs
Speaking of non sequiturs...
I'm not opining on the complexity of clinical affairs, I'm opining on your attempt to claim that a routine is complex because it has a 30 page manual.
IT Guy, whoever you may be -
I am a physician with years of in-hospital teaching and clinical experience. My quick review of the discharge process manual suggests this EHR is a text-book case of how to make a moderately complex process mind-numbingly complex. Just look at how it takes 23(!) steps to write a list of hospital medications and a list discharge medications, and write prescriptions for them.
It is true that one might end up writing a long manual to fully document software that is simple to use. But this software appears ridiculously complex to use given the clinical context.
IT Guy writes:
"I'm not opining on the complexity of clinical affairs"
IT Guy had written:
"Having a 30 page [clinical training] manual [for patient discharge] does not mean a process is complex"
Clearly, IT guy was opining on the complexity of something else - making spaghetti, perhaps.
I am a physician with years of in-hospital teaching and clinical experience. My quick review of the discharge process manual suggests this EHR is a text-book case of how to make a moderately complex process mind-numbingly complex. Just look at how it takes 23(!) steps to write a list of hospital medications and a list discharge medications, and write prescriptions for them.
You make a very good case for that section of the discharge process being overly complex. Your case is certainly more compelling than "the manual has 30 pages". Maybe you should have written the article.
Clearly, IT guy was opining on the complexity of something else - making spaghetti, perhaps.
I was opining on your use of logical fallacies.
IT Guy, whoever you are -
The complexity would be glaringly obvious to any physician who has done hospital medicine after paging through the manual for a minute or two. I do believe that MedInformaticsMD did not feel he had to belabor exactly why the manual and the process were overly complex, since much of our audience is physicians and health care professionals.
IT Guy writes:
"I was opining on your use of logical fallacies."
IT Guy, if I were young Spock it would be you I'd put in a rescue pod and eject to the frozen Delta Vega.
Roy writes:
"I do believe that MedInformaticsMD did not feel he had to belabor exactly why the manual and the process were overly complex"
In fact, it's because I believe that those who are intellectually curious will download the PDF's and examine them. I believe readers downloading these PDF's can decide for themselves, physician or not, whether these applications are the miracles they've been made out to be, or, like much other software, are overly complex solutions looking for a problem. My opinion is clearly obvious.
I will apologize in advance, because I only have a few minutes and did not download the PDFs. My point applies to EMRs in general, however, not solely to whatever system is in place at the offending hospital.
If a discharge process requires 23 steps, my first question would be, "Does the actual software require 23 steps, or does the process (a process that was most likely designed by people within the hospital) require 23 steps?"
I am not making apologies for the current generation of EMR systems on the market. I do believe, however, it's important to distinguish between stupidity on the part of the vendors who build the systems, and stupidity on the part of the in-house hospital teams that design processes within the systems.
Taotechuck writes:
It's important to distinguish between stupidity on the part of the vendors who build the systems, and stupidity on the part of the in-house hospital teams that design processes within the systems.
The easiest way to respond is for me to direct you to my eight part series on the mission hostile user experience presented by many commercial EHR's here.
It's a fast read. Major point: if HIT vendors can't get "process-lite" components correct (e.g., displays of data, order entry, allowing a clinician to understanding how well a patient's been eating, etc.), it's a stretch to imagine they could produce optimal IT that could enhance complex operational aspects of care such as discharge.
There's a systemic problem IMO in HIT design decision processes, with root causes such as talent mismanagement and indifference, among others.
Regarding "IT Guy's" comments, see my followup post here. HIT organizations may on fact be trying hard to suppress those who can actually help them solve these problems.
-- SS
Post a Comment